Writing an Application
actix-web provides various primitives to build web servers and applications with Rust. It provides routing, middleware, pre-processing of requests, post-processing of responses, etc.
actix-web servers are built around the
App instance. It is used for registering routes for resources and middleware. It also stores application state shared across all handlers within the same scope.
scope acts as a namespace for all routes, i.e. all routes for a specific application scope have the same url path prefix. The application prefix always contains a leading "/" slash. If a supplied prefix does not contain leading slash, it is automatically inserted. The prefix should consist of value path segments.
For an application with scope
/app, any request with the paths
/app/testwould match; however, the path
/applicationwould not match.
In this example, an application with the
/app prefix and an
index.html resource is created. This resource is available through the
For more information, check the URL Dispatch section.
Application state is shared with all routes and resources within the same scope. State can be accessed with the
web::Data<T> extractor where
T is the type of the state. State is also accessible for middleware.
Let's write a simple application and store the application name in the state:
Next, pass in the state when initializing the App and start the application:
Any number of state types could be registered within the application.
Shared Mutable State
HttpServer accepts an application factory rather than an application instance. An
HttpServer constructs an application instance for each thread. Therefore, application data must be constructed multiple times. If you want to share data between different threads, a shareable object should be used, e.g.
In the following example, we will write an application with mutable, shared state. First, we define our state and create our handler:
and register the data in an
- State initialized inside the closure passed to
HttpServer::newis local to the worker thread and may become de-synced if modified.
- To achieve globally shared state, it must be created outside of the closure passed to
HttpServer::newand moved/cloned in.
Using an Application Scope to Compose Applications
web::scope() method allows setting a resource group prefix. This scope represents a resource prefix that will be prepended to all resource patterns added by the resource configuration. This can be used to help mount a set of routes at a different location than the original author intended while still maintaining the same resource names.
In the above example, the
show_users route will have an effective route pattern of
/users/show instead of
/show because the application's scope argument will be prepended to the pattern. The route will then only match if the URL path is
/users/show, and when the
HttpRequest.url_for() function is called with the route name
show_users, it will generate a URL with that same path.
Application guards and virtual hosting
You can think of a guard as a simple function that accepts a request object reference and returns true or false. Formally, a guard is any object that implements the
Guard trait. Actix Web provides several guards. You can check the functions section of the API docs.
One of the provided guards is
Host. It can be used as a filter based on request header information.
For simplicity and reusability both
web::Scope provide the
configure method. This function is useful for moving parts of the configuration to a different module or even library. For example, some of the resource's configuration could be moved to a different module.
The result of the above example would be:
/ -> "/"
/app -> "app"
/api/test -> "test"
ServiceConfig can have its own