Struct tide::Server[−][src]

pub struct Server<State> { /* fields omitted */ }

Expand description

An HTTP server.

Servers are built up as a combination of state, endpoints and middleware:

Server state is user-defined, and is provided via the Server::with_state function. The state is available as a shared reference to all app endpoints.
Endpoints provide the actual application-level code corresponding to particular URLs. The Server::at method creates a new route (using standard router syntax), which can then be used to register endpoints for particular HTTP request types.
Middleware extends the base Tide framework with additional request or response processing, such as compression, default headers, or logging. To add middleware to an app, use the Server::with method.

Implementations

[src]

impl<State> Server<State> where
State: Clone + Send + Sync + 'static,

[src]

pub fn with_state(state: State) -> Self

Create a new Tide server with shared application scoped state.

Application scoped state is useful for storing items

pub fn at<'a>(&'a mut self, path: &str) -> Route<'a, State>

Add a new route at the given path, relative to root.

Routing means mapping an HTTP request to an endpoint. Here Tide applies a “table of contents” approach, which makes it easy to see the overall app structure. Endpoints are selected solely by the path and HTTP method of a request: the path determines the resource and the HTTP verb the respective endpoint of the selected resource. Example:

app.at("/").get(|_| async { Ok("Hello, world!") });

A path is comprised of zero or many segments, i.e. non-empty strings separated by ‘/’. There are two kinds of segments: concrete and wildcard. A concrete segment is used to exactly match the respective part of the path of the incoming request. A wildcard segment on the other hand extracts and parses the respective part of the path of the incoming request to pass it along to the endpoint as an argument. A wildcard segment is written as :name, which creates an endpoint parameter called name. It is not possible to define wildcard segments with different names for otherwise identical paths.

Alternatively a wildcard definitions can start with a *, for example *path, which means that the wildcard will match to the end of given path, no matter how many segments are left, even nothing.

The name of the parameter can be omitted to define a path that matches the required structure, but where the parameters are not required. : will match a segment, and * will match an entire path.

Here are some examples omitting the HTTP verb based endpoint selection:

app.at("/");
app.at("/hello");
app.at("add_two/:num");
app.at("files/:user/*");
app.at("static/*path");
app.at("static/:context/:");

There is no fallback route matching, i.e. either a resource is a full match or not, which means that the order of adding resources has no effect.

[src]

pub fn with<M>(&mut self, middleware: M) -> &mut Self where
M: Middleware<State>,

Add middleware to an application.

Middleware provides customization of the request/response cycle, such as compression, logging, or header modification. Middleware is invoked when processing a request, and can either continue processing (possibly modifying the response) or immediately return a response. See the Middleware trait for details.

Middleware can only be added at the “top level” of an application, and is processed in the order in which it is applied.

[src]

pub async fn listen<L: ToListener<State>>(self, listener: L) -> Result<()>

Asynchronously serve the app with the supplied listener.

This is a shorthand for calling Server::bind, logging the ListenInfo instances from Listener::info, and then calling Listener::accept.

Examples

let mut app = tide::new();
app.at("/").get(|_| async { Ok("Hello, world!") });
app.listen("127.0.0.1:8080").await?;

[src]

pub async fn bind<L: ToListener<State>>(
self,
listener: L
) -> Result<<L as ToListener<State>>::Listener>

Asynchronously bind the listener.

Bind the listener. This starts the listening process by opening the necessary network ports, but not yet accepting incoming connections. Listener::listen should be called after this to start accepting connections.

When calling Listener::info multiple ListenInfo instances may be returned. This is useful when using for example ConcurrentListener which enables a single server to listen on muliple ports.

Examples

use tide::prelude::*;

let mut app = tide::new();
app.at("/").get(|_| async { Ok("Hello, world!") });
let mut listener = app.bind("127.0.0.1:8080").await?;
for info in listener.info().iter() {
    println!("Server listening on {}", info);
}
listener.accept().await?;

[src]

pub async fn respond<Req, Res>(&self, req: Req) -> Result<Res> where
Req: Into<Request>,
Res: From<Response>,

Respond to a Request with a Response.

This method is useful for testing endpoints directly, or for creating servers over custom transports.

Examples

use tide::http::{Url, Method, Request, Response};

let mut app = tide::new();
app.at("/").get(|_| async { Ok("hello world") });

let req = Request::new(Method::Get, Url::parse("https://example.com")?);
let res: Response = app.respond(req).await?;

assert_eq!(res.status(), 200);

[src]

pub fn state(&self) -> &State

Gets a reference to the server’s state. This is useful for testing and nesting:

Example

let mut app = tide::with_state(SomeAppState);
let mut admin = tide::with_state(app.state().clone());
admin.at("/").get(|_| async { Ok("nested app with cloned state") });
app.at("/").nest(admin);