actix-website/docs/application.md

title
Application

import CodeBlock from "@site/src/components/code_block.js";

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.

All 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.

An application's 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, /app/, or /app/test would match; however, the path /application would not match.

In this example, an application with the /app prefix and an index.html resource is created. This resource is available through the /app/index.html url.

For more information, check the URL Dispatch section.

State

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. Send + Sync.

Internally, web::Data uses Arc. So in order to avoid creating two Arcs, we should create our Data before registering it using App::app_data().

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 App:

Key takeaways:

• State initialized inside the closure passed to HttpServer::new is 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::new and moved/cloned in.

Using an Application Scope to Compose Applications

The 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.

For example:

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 Header. It can be used as a filter based on request header information.

Configure

For simplicity and reusability both App and 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"

Each ServiceConfig can have its own data, routes, and services.