Rocket

Question 1

What are the core philosophies of Rocket?

Answer 1

1. Security, correctness, and developer experience are paramount.

The path of least resistance should lead you to the most secure, correct web application, though security and correctness should not come at the cost of a degraded developer experience. Rocket is easy to use while taking great measures to ensure that your application is secure and correct without cognitive overhead.

2. All request handling information should be typed and self-contained.

Because the web and HTTP are themselves untyped (or stringly typed, as some call it), this means that something or someone has to convert strings to native types. Rocket does this for you with zero programming overhead. What’s more, Rocket’s request handling is self-contained with zero global state: handlers are regular functions with regular arguments.

3. Decisions should not be forced.

Templates, serialization, sessions, and just about everything else are all pluggable, optional components. While Rocket has official support and libraries for each of these, they are completely optional and swappable.

Question 2

What steps summarizes the Rocket lifecycle?

Answer 2

1. Routing

Rocket parses an incoming HTTP request into native structures that your code operates on indirectly. Rocket determines which request handler to invoke by matching against route attributes declared in your application.

2. Validation

Rocket validates the incoming request against types and guards present in the matched route. If validation fails, Rocket forwards the request to the next matching route or calls an error handler.

3. Processing

The request handler associated with the route is invoked with validated arguments. This is the main business logic of an application. Processing completes by returning a Response.

4. Response

The returned Response is processed. Rocket generates the appropriate HTTP response and sends it to the client. This completes the lifecycle. Rocket continues listening for requests, restarting the lifecycle for each incoming request.

Question 3

What is a rocket handler?

Answer 3

A handler is simply a function that takes an arbitrary number of arguments and returns any arbitrary type.

Question 4

What is a Rocket route?

Answer 4

A route is a combination of:

* A set of parameters to match an incoming request against.
* A handler to process the request and return a response.

Question 5

What does a route declaration look like?

Answer 5

[get(“/world”)]

Question 6

What is the normal way of importing rocket and why?

Answer 6

[macro_use] extern crate rocket;

Normally, rocket is imported with:

Explicitly importing with #[macro_use] imports macros globally, allowing you to use Rocket’s macros anywhere in your application without importing them explicitly.

Question 7

Before Rocket can dispatch requests to a route, the route needs to be __

Answer 7

Mounted.

The mount method takes as input:

1. A base path to namespace a list of routes under, here, /hello.
2. A list of routes via the routes! macro: here, routes![world], with multiple routes: routes![a, b, c].

The mount method, like all other builder methods on Rocket, can be chained any number of times, and routes can be reused by mount points.

Example:

rocket::build()
.mount(“/hello”, routes![world])
.mount(“/hi”, routes![world])

Question 8

There are two ways to launch a Rocket application, which is the preferred approach?

Answer 8

[launch]

The first and preferred approach is via the #[launch] route attribute, which generates a main function that sets up an async runtime and starts the server.

Example:

#[launch]
fn rocket() -> _ {
    rocket::build().mount("/hello", routes![world])
}

The second approach uses the #[rocket::main] route attribute. #[rocket::main] also generates a main function that sets up an async runtime but unlike #[launch], allows you to start the server:

#[rocket::main]
async fn main() {
    rocket::build()
        .mount("/hello", routes![world])
        .launch()
        .await;
}

Question 9

You should prefer __ libraries instead of __ equivalents inside Rocket applications.

Answer 9

You should prefer ASYNC-READY libraries instead of SYNCHRONOUS equivalents inside Rocket applications.

Question 10

Futures and async functions should only __ on operations and never __.

Answer 10

Futures and async fns should only .await on operations and never block.

Some common examples of blocking include locking non-async mutexes, joining threads, or using non-async library functions (including those in std) that perform I/O.

If necessary, you can convert a synchronous operation to an async one with tokio::task::spawn_blocking:

Question 11

With a route attribute, you can—among other things—ask Rocket to automatically validate:

Answer 11

you can ask Rocket to automatically validate:

Question 12

With a route attribute, you can—among other things—ask Rocket to automatically validate:

Answer 12

• The type of a dynamic path segment.
• The type of several dynamic path segments.
• The type of incoming body data.
• The types of query strings, forms, and form values.
• The expected incoming or outgoing format of a request.
• Any arbitrary, user-defined security or validation policies.

Question 13

A Rocket route attribute can be any one of…

Answer 13

get, put, post, delete, head, patch, or options

Question 14

What is a parameter guard?

Answer 14

Any type that implements the FromParam trait, which is used by Rocket to parse dynamic path segment string values into a given type.

Question 15

You can match against multiple segments by using __ in a route path. Such parameters must implement __ and be the __ __ of a path.

Answer 15

bracket param… bracket