diff --git a/content/docs/_index.md b/content/docs/_index.md index e827e63..b1ad3cd 100644 --- a/content/docs/_index.md +++ b/content/docs/_index.md @@ -15,7 +15,7 @@ in no time. The documentation on this website focusses primarily on the Actix Web framework. For information about the actor framework called Actix, check out the [Actix book][actix-book] (or the lower level [actix API docs][actix-docs]). Otherwise, head on to the [getting started guide][getting-started]. -If you already know your ways around and you need specific information you might want to read the +If you already know your way around and you need specific information you might want to read the [actix-web API docs][actix-web-docs]. [getting-started]: ./getting-started diff --git a/content/docs/application.md b/content/docs/application.md index 02040a6..ce4bc99 100644 --- a/content/docs/application.md +++ b/content/docs/application.md @@ -23,7 +23,7 @@ prefix should consist of value path segments. {{< include-example example="application" file="app.rs" section="setup" >}} -In this example, an application with the `/app` prefix and a `index.html` resource are created. This +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][usingappprefix] section. @@ -38,7 +38,7 @@ Let's write a simple application and store the application name in the state: {{< include-example example="application" file="state.rs" section="setup" >}} -and pass in the state when initializing the App, and start the application: +Next, pass in the state when initializing the App and start the application: {{< include-example example="application" file="state.rs" section="start_app" >}} diff --git a/content/docs/errors.md b/content/docs/errors.md index 13275ee..3885bb5 100644 --- a/content/docs/errors.md +++ b/content/docs/errors.md @@ -11,8 +11,8 @@ Actix-web uses its own [`actix_web::error::Error`][actixerror] type and If a handler returns an `Error` (referring to the [general Rust trait `std::error::Error`][stderror]) in a `Result` that also implements the `ResponseError` trait, -actix-web will render that error as an HTTP response with it's corresponding -[`actix_web::http::StatusCode`][status_code]. Internal server error is generated by default: +actix-web will render that error as an HTTP response with its corresponding +[`actix_web::http::StatusCode`][status_code]. An internal server error is generated by default: ```rust pub trait ResponseError { diff --git a/content/docs/extractors.md b/content/docs/extractors.md index 36ce427..52fd021 100644 --- a/content/docs/extractors.md +++ b/content/docs/extractors.md @@ -7,7 +7,7 @@ weight: 170 # Type-safe information extraction Actix-web provides a facility for type-safe request information access called *extractors* -(ie, `impl FromRequest`). By default, actix-web provides several extractor implementations. +(i.e., `impl FromRequest`). By default, actix-web provides several extractor implementations. An extractor can be accessed as an argument to a handler function. Actix-web supports up to 12 extractors per handler function. Argument position does not matter. @@ -51,10 +51,10 @@ trait from *serde*. {{< include-example example="extractors" file="json_one.rs" section="json-one" >}} -Some extractors provide a way to configure the extraction process. Json extractor -[*JsonConfig*][jsonconfig] type for configuration. To configure an extractor, pass its -configuration object to the resource's `.data()` method. In case of a *Json* extractor -it returns a *JsonConfig*. You can configure the maximum size of the json payload as +Some extractors provide a way to configure the extraction process. To configure +an extractor, pass its configuration object to the resource's `.data()` method. +In the case of *Json* extractor it returns a [*JsonConfig*][jsonconfig]. +You can configure the maximum size of the JSON payload as well as a custom error handler function. The following example limits the size of the payload to 4kb and uses a custom error handler. @@ -100,7 +100,7 @@ Here is an example of a handler that stores the number of processed requests: {{< include-example example="request-handlers" file="main.rs" section="data" >}} Although this handler will work, `self.0` will be different depending on the number of threads and -number of requests processed per thread. A proper implementation would use `Arc` and `AtomicUsize`. +number of requests processed per thread. A proper implementation would use `web::Data` and `AtomicUsize`. {{< include-example example="request-handlers" file="handlers_arc.rs" section="arc" >}} diff --git a/content/docs/getting-started.md b/content/docs/getting-started.md index 8620de9..8113005 100644 --- a/content/docs/getting-started.md +++ b/content/docs/getting-started.md @@ -37,7 +37,7 @@ extracted from a request (see `FromRequest` trait) and returns a type that can b Notice that some of these handlers have routing information attached directly using the built-in macros. These allow you to specify the method and path that the handler should respond to. You will -see below how to register the other route that does not use a routing macro. +see below how to register `manual_hello` (i.e. routes that do not use a routing macro). Next, create an `App` instance and register the request handlers. Use `App::service` for the handlers using routing macros and `App::route` for manually routed handlers, declaring the path diff --git a/content/docs/handlers.md b/content/docs/handlers.md index e34fc0d..b2d1039 100644 --- a/content/docs/handlers.md +++ b/content/docs/handlers.md @@ -7,8 +7,8 @@ weight: 160 # Request Handlers A request handler is an async function that accepts zero or more parameters that can be extracted -from a request (ie, [*impl FromRequest*][implfromrequest]) and returns a type that can -be converted into an HttpResponse (ie, [*impl Responder*][respondertrait]). +from a request (i.e., [*impl FromRequest*][implfromrequest]) and returns a type that can +be converted into an HttpResponse (i.e., [*impl Responder*][respondertrait]). Request handling happens in two stages. First the handler object is called, returning any object that implements the [*Responder*][respondertrait] trait. Then, `respond_to()` is @@ -17,7 +17,7 @@ called on the returned object, converting itself to a `HttpResponse` or `Error`. By default actix-web provides `Responder` implementations for some standard types, such as `&'static str`, `String`, etc. -> For a complete list of implementations, check [*Responder documentation*][responderimpls]. +> For a complete list of implementations, check the [*Responder documentation*][responderimpls]. Examples of valid handlers: @@ -59,7 +59,7 @@ Let's create a response for a custom type that serializes to an `application/jso ## Streaming response body Response body can be generated asynchronously. In this case, body must implement -the stream trait `Stream`, i.e: +the stream trait `Stream`, i.e.: {{< include-example example="async-handlers" file="stream.rs" section="stream" >}} diff --git a/content/docs/server.md b/content/docs/server.md index 3b53c8f..e34d986 100644 --- a/content/docs/server.md +++ b/content/docs/server.md @@ -42,7 +42,7 @@ requests. Application state is not shared between the threads, and handlers are their copy of the state with no concurrency concerns. > Application state does not need to be `Send` or `Sync`, but application -factory must be `Send` + `Sync`. +factories must be `Send` + `Sync`. To share state between worker threads, use an `Arc`. Special care should be taken once sharing and synchronization are introduced. In many cases, performance costs are inadvertently introduced as a diff --git a/content/docs/url-dispatch.md b/content/docs/url-dispatch.md index b6f337b..025f9b7 100644 --- a/content/docs/url-dispatch.md +++ b/content/docs/url-dispatch.md @@ -11,8 +11,8 @@ matching language. If one of the patterns matches the path information associate a particular handler object is invoked. > A request handler is a function that accepts zero or more parameters that can be extracted -> from a request (ie, [*impl FromRequest*][implfromrequest]) and returns a type that can -> be converted into an HttpResponse (ie, [*impl Responder*][implresponder]). More information +> from a request (i.e., [*impl FromRequest*][implfromrequest]) and returns a type that can +> be converted into an HttpResponse (i.e., [*impl Responder*][implresponder]). More information > is available in the [handler section][handlersection]. # Resource configuration diff --git a/content/docs/whatis.md b/content/docs/whatis.md index 980aa13..0b44e87 100644 --- a/content/docs/whatis.md +++ b/content/docs/whatis.md @@ -9,7 +9,7 @@ weight: 100 Long ago, `actix-web` was built on top of `actix`, a powerful and fast actor system. Now, `actix-web` is largely unrelated to the actor framework and is built using a different system. Though `actix` is still maintained, its usefulness as a general tool is diminishing as the -futures and async/await ecosystem matures. At this time, the use of `actix` it is only required for +futures and async/await ecosystem matures. At this time, the use of `actix` is only required for WebSocket endpoints. We call `actix-web` a powerful and pragmatic framework. For all intents and purposes it's a