2017-04-17 02:48:59 +00:00
|
|
|
# Overview
|
|
|
|
|
2018-10-22 21:47:35 +00:00
|
|
|
Rocket provides primitives to build web servers and applications with Rust:
|
|
|
|
Rocket provides routing, pre-processing of requests, and post-processing of
|
|
|
|
responses; the rest is up to you. Your application code instructs Rocket on what
|
|
|
|
to pre-process and post-process and fills the gaps between pre-processing and
|
|
|
|
post-processing.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
## Lifecycle
|
|
|
|
|
|
|
|
Rocket's main task is to listen for incoming web requests, dispatch the request
|
|
|
|
to the application code, and return a response to the client. We call the
|
2017-07-03 05:51:24 +00:00
|
|
|
process that goes from request to response the "lifecycle". We summarize the
|
|
|
|
lifecycle as the following sequence of steps:
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
1. **Routing**
|
|
|
|
|
2017-07-03 05:51:24 +00:00
|
|
|
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.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
2. **Validation**
|
|
|
|
|
2017-07-03 05:51:24 +00:00
|
|
|
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_.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
3. **Processing**
|
|
|
|
|
2017-07-03 05:51:24 +00:00
|
|
|
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`.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
4. **Response**
|
|
|
|
|
2017-07-03 05:51:24 +00:00
|
|
|
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.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
The remainder of this section details the _routing_ phase as well as additional
|
|
|
|
components needed for Rocket to begin dispatching requests to request handlers.
|
2017-07-10 11:59:55 +00:00
|
|
|
The sections following describe the request and response phases as well as other
|
|
|
|
components of Rocket.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
## Routing
|
|
|
|
|
2017-07-03 05:51:24 +00:00
|
|
|
Rocket applications are centered around routes and handlers. A _route_ is a
|
|
|
|
combination of:
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
* A set of parameters to match an incoming request against.
|
|
|
|
* A handler to process the request and return a response.
|
|
|
|
|
2017-07-03 05:51:24 +00:00
|
|
|
A _handler_ is simply a function that takes an arbitrary number of arguments and
|
|
|
|
returns any arbitrary type.
|
|
|
|
|
2017-04-17 02:48:59 +00:00
|
|
|
The parameters to match against include static paths, dynamic paths, path
|
|
|
|
segments, forms, query strings, request format specifiers, and body data. Rocket
|
|
|
|
uses attributes, which look like function decorators in other languages, to make
|
|
|
|
declaring routes easy. Routes are declared by annotating a function, the
|
|
|
|
handler, with the set of parameters to match against. A complete route
|
|
|
|
declaration looks like this:
|
|
|
|
|
|
|
|
```rust
|
2020-02-15 11:43:47 +00:00
|
|
|
# #![feature(proc_macro_hygiene)]
|
|
|
|
# #[macro_use] extern crate rocket;
|
|
|
|
|
2017-04-17 02:48:59 +00:00
|
|
|
#[get("/world")] // <- route attribute
|
|
|
|
fn world() -> &'static str { // <- request handler
|
2020-02-15 11:43:47 +00:00
|
|
|
"hello, world!"
|
2017-04-17 02:48:59 +00:00
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
This declares the `world` route to match against the static path `"/world"` on
|
|
|
|
incoming `GET` requests. The `world` route is simple, but additional route
|
|
|
|
parameters are necessary when building more interesting applications. The
|
2018-10-16 05:50:35 +00:00
|
|
|
[Requests](../requests) section describes the available options for
|
2017-04-17 02:48:59 +00:00
|
|
|
constructing routes.
|
|
|
|
|
|
|
|
## Mounting
|
|
|
|
|
2018-10-22 21:47:35 +00:00
|
|
|
Before Rocket can dispatch requests to a route, the route needs to be _mounted_:
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
```rust
|
2020-02-15 11:43:47 +00:00
|
|
|
# #![feature(proc_macro_hygiene)]
|
|
|
|
# #[macro_use] extern crate rocket;
|
|
|
|
|
|
|
|
# #[get("/world")]
|
|
|
|
# fn world() -> &'static str {
|
|
|
|
# "hello, world!"
|
|
|
|
# }
|
|
|
|
|
2018-10-22 21:47:35 +00:00
|
|
|
fn main() {
|
|
|
|
rocket::ignite().mount("/hello", routes![world]);
|
|
|
|
}
|
2017-04-17 02:48:59 +00:00
|
|
|
```
|
|
|
|
|
2018-10-22 21:47:35 +00:00
|
|
|
The `mount` method takes as input:
|
|
|
|
|
2019-05-11 02:39:38 +00:00
|
|
|
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]`.
|
2018-10-22 21:47:35 +00:00
|
|
|
|
2017-07-03 05:51:24 +00:00
|
|
|
This creates a new `Rocket` instance via the `ignite` function and mounts the
|
2018-10-22 21:47:35 +00:00
|
|
|
`world` route to the `"/hello"` path, making Rocket aware of the route. `GET`
|
|
|
|
requests to `"/hello/world"` will be directed to the `world` function.
|
|
|
|
|
|
|
|
! note: In many cases, the base path will simply be `"/"`.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
### Namespacing
|
|
|
|
|
|
|
|
When a route is declared inside a module other than the root, you may find
|
|
|
|
yourself with unexpected errors when mounting:
|
|
|
|
|
2020-02-15 11:43:47 +00:00
|
|
|
```rust,compile_fail
|
|
|
|
# #![feature(proc_macro_hygiene)]
|
|
|
|
# #[macro_use] extern crate rocket;
|
|
|
|
|
2017-04-17 02:48:59 +00:00
|
|
|
mod other {
|
|
|
|
#[get("/world")]
|
|
|
|
pub fn world() -> &'static str {
|
|
|
|
"Hello, world!"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-11 02:39:38 +00:00
|
|
|
#[get("/hello")]
|
|
|
|
pub fn hello() -> &'static str {
|
|
|
|
"Hello, outside world!"
|
|
|
|
}
|
|
|
|
|
2017-04-17 02:48:59 +00:00
|
|
|
use other::world;
|
|
|
|
|
|
|
|
fn main() {
|
2020-02-15 11:43:47 +00:00
|
|
|
// error[E0425]: cannot find value `static_rocket_route_info_for_world` in this scope
|
|
|
|
rocket::ignite().mount("/hello", routes![hello, world]);
|
2017-04-17 02:48:59 +00:00
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
This occurs because the `routes!` macro implicitly converts the route's name
|
|
|
|
into the name of a structure generated by Rocket's code generation. The solution
|
2018-10-22 21:47:35 +00:00
|
|
|
is to refer to the route using a namespaced path instead:
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
```rust
|
2020-02-15 11:43:47 +00:00
|
|
|
# #![feature(proc_macro_hygiene)]
|
|
|
|
# #[macro_use] extern crate rocket;
|
|
|
|
|
|
|
|
# #[get("/")] pub fn hello() {}
|
|
|
|
# mod other { #[get("/world")] pub fn world() {} }
|
|
|
|
|
2019-05-11 02:39:38 +00:00
|
|
|
rocket::ignite().mount("/hello", routes![hello, other::world]);
|
2017-04-17 02:48:59 +00:00
|
|
|
```
|
|
|
|
|
|
|
|
## Launching
|
|
|
|
|
|
|
|
Now that Rocket knows about the route, you can tell Rocket to start accepting
|
|
|
|
requests via the `launch` method. The method starts up the server and waits for
|
|
|
|
incoming requests. When a request arrives, Rocket finds the matching route and
|
|
|
|
dispatches the request to the route's handler.
|
|
|
|
|
|
|
|
We typically call `launch` from the `main` function. Our complete _Hello,
|
|
|
|
world!_ application thus looks like:
|
|
|
|
|
|
|
|
```rust
|
2019-06-20 06:03:21 +00:00
|
|
|
#![feature(proc_macro_hygiene)]
|
2017-04-17 02:48:59 +00:00
|
|
|
|
2018-10-05 04:44:42 +00:00
|
|
|
#[macro_use] extern crate rocket;
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
#[get("/world")]
|
|
|
|
fn world() -> &'static str {
|
|
|
|
"Hello, world!"
|
|
|
|
}
|
|
|
|
|
|
|
|
fn main() {
|
2020-02-15 11:43:47 +00:00
|
|
|
# if false {
|
2017-04-17 02:48:59 +00:00
|
|
|
rocket::ignite().mount("/hello", routes![world]).launch();
|
2020-02-15 11:43:47 +00:00
|
|
|
# }
|
2017-04-17 02:48:59 +00:00
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2018-10-05 04:44:42 +00:00
|
|
|
Note the `#![feature]` line: this tells Rust that we're opting in to compiler
|
2018-10-22 21:47:35 +00:00
|
|
|
features available in the nightly release channel. This line **must** be in the
|
|
|
|
crate root, typically `main.rs`. We've also imported the `rocket` crate and all
|
|
|
|
of its macros into our namespace via `#[macro_use] extern crate rocket`.
|
|
|
|
Finally, we call the `launch` method in the `main` function.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
Running the application, the console shows:
|
|
|
|
|
|
|
|
```sh
|
|
|
|
🔧 Configured for development.
|
|
|
|
=> address: localhost
|
|
|
|
=> port: 8000
|
|
|
|
=> log: normal
|
2018-10-23 08:22:46 +00:00
|
|
|
=> workers: [logical cores * 2]
|
2017-07-03 05:51:24 +00:00
|
|
|
=> secret key: generated
|
|
|
|
=> limits: forms = 32KiB
|
2018-10-22 21:47:35 +00:00
|
|
|
=> keep-alive: 5s
|
2017-07-03 05:51:24 +00:00
|
|
|
=> tls: disabled
|
2018-11-04 10:25:51 +00:00
|
|
|
🛰 Mounting '/hello':
|
|
|
|
=> GET /hello/world (world)
|
2017-07-03 05:51:24 +00:00
|
|
|
🚀 Rocket has launched from http://localhost:8000
|
2017-04-17 02:48:59 +00:00
|
|
|
```
|
|
|
|
|
2018-10-22 21:47:35 +00:00
|
|
|
If we visit `localhost:8000/hello/world`, we see `Hello, world!`, exactly as we
|
|
|
|
expected.
|
2017-04-17 02:48:59 +00:00
|
|
|
|
|
|
|
A version of this example's complete crate, ready to `cargo run`, can be found
|
2018-10-22 21:47:35 +00:00
|
|
|
on [GitHub](@example/hello_world). You can find dozens of other complete
|
|
|
|
examples, spanning all of Rocket's features, in the [GitHub examples
|
2018-10-16 05:50:35 +00:00
|
|
|
directory](@example/).
|