mirror of
https://github.com/actix/actix-website
synced 2024-11-27 18:12:57 +01:00
Fix some typos/grammatical errors (#219)
This commit is contained in:
parent
defe1142df
commit
3ed587a81a
@ -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
|
||||
|
@ -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" >}}
|
||||
|
||||
|
@ -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 {
|
||||
|
@ -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" >}}
|
||||
|
||||
|
@ -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
|
||||
|
@ -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<Item=Bytes, Error=Error>`, i.e:
|
||||
the stream trait `Stream<Item=Bytes, Error=Error>`, i.e.:
|
||||
|
||||
{{< include-example example="async-handlers" file="stream.rs" section="stream" >}}
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user