You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/book/v5/core-features/content-validation.md
+30-46Lines changed: 30 additions & 46 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,25 +4,19 @@
4
4
5
5
**Content Negotiation** is performed by an application in order :
6
6
7
-
- To match the requested representation as specified by the client via the Accept header with a representation the
8
-
application can deliver.
7
+
- To match the requested format as specified by the client via the `Accept` header with a format the application can deliver.
9
8
- To determine the `Content-Type` of incoming data and deserialize it so the application can utilize it.
10
9
11
-
Essentially, content negotiation is the *client* telling the server what it is sending and what it wants in return, and
12
-
the server determining if it can do what the client requests.
10
+
Essentially, content negotiation is the *client* telling the server what it is sending and what it wants in return, and the server determining if it can do what the client requests.
13
11
14
-
Content negotiation validation in **Dotkernel API** happens through middleware, and it ensures that the incoming
15
-
request and the outgoing response conform to the content types specified in the config file for all routes or for a
16
-
specific route.
17
-
18
-
It performs validation on the `Accept` and `Content-Type` headers of the request and response and returning appropriate
19
-
errors responses when necessary.
12
+
Content negotiation validation in **Dotkernel API** happens through middleware, and it ensures that the incoming request and the outgoing response conform to the content types specified in the config file for all routes or for a specific route.
13
+
It performs validation on the `Accept` and `Content-Type` headers of the request and response.
14
+
It returns appropriate errors responses when necessary.
20
15
21
16
## Configuration
22
17
23
-
In Dotkernel API the configuration file for content negotiation is held
24
-
in `config/autoload/content-negotiation.global.php`
25
-
and the array looks like this:
18
+
In Dotkernel API the configuration file for content negotiation is `config/autoload/content-negotiation.global.php`.
19
+
The contents look like this:
26
20
27
21
```php
28
22
return [
@@ -45,43 +39,37 @@ return [
45
39
];
46
40
```
47
41
48
-
Except the `default` key, all your keys must match the route name, for example in Dotkernel API we have the route to
49
-
list all admins, which name is `admin.list`.
50
-
51
-
If you did not specify a route name to configure your specifications about content negotiation, the `default` one will
52
-
be in place. The `default` key is `mandatory`.
42
+
Excepting the `default` key, all your keys must match the route name.
43
+
For example, in Dotkernel API we have the route to list all admins, whose name is `admin.list`.
44
+
If you did not specify content negotiation for a given route, the `default` setup will be used.
45
+
The `default` key is mandatory.
53
46
54
-
Every route configuration must come with `Accept` and `Content-Type` keys, basically this will be the keys that the
55
-
request headers will be validated against.
47
+
Every route configuration must come with `Accept` and `Content-Type` keys.
48
+
These keys will be used as request headers for validation.
56
49
57
50
## Accept Negotiation
58
51
59
-
This specifies that your server can return that representation, or at least one of the representation sent by the
60
-
client.
52
+
This specifies that your server can return that format, or at least one of the formats sent by the client.
61
53
62
54
```shell
63
55
GET /admin HTTP/1.1
64
56
Accept: application/json
65
57
```
66
58
67
-
This request indicates the client wants `application/json` in return. Now the server, through the config file will try
68
-
to validate if that representation can be returned, basically if `application/json` is presented in the `Accept` key.
59
+
This request indicates the client wants `application/json` in return.
60
+
The server will use the config file to see if that format can be returned, basically if `application/json` is present in the `Accept` key.
69
61
70
-
If the representation cannot be returned, a status code `406 - Not Acceptable` will be returned.
62
+
- If the format cannot be returned, a status code `406 - Not Acceptable` will be returned.
63
+
- If the format can be returned, the server should report the media type through the `Content-Type` header in the response.
71
64
72
-
If the representation can be returned, the server should report the media type through `Content-Type` header of the
73
-
response.
65
+
> Due to how these validations are made, the server can return a more generic media type, e.g. for a `json` media type.
66
+
> For example, if the client sends `Accept: application/vnd.api+json`, but you configured your `Accept` key as `application/json`, the format will still be returned as `json`.
74
67
75
-
> Due to how these validations are made, for a `json` media type, the server can return a more generic media type,
76
-
> for example, if the clients send `Accept: application/vnd.api+json` and you configured your `Accept` key
77
-
> as `application/json` the representation will still be returned as `json`.
78
-
79
-
> If the `Accept` header of the request contains `*/*` it means that whatever the server can return it is OK, so it can
80
-
> return anything.
68
+
> If the `Accept` header of the request contains `*/*` it means that whatever format the server can return is OK.
81
69
82
70
## Content-Type Negotiation
83
71
84
-
The second aspect of content negotiation is the `Content-Type` header and determine the server can deserialize the data.
72
+
The second aspect of content negotiation is the `Content-Type` header and to determine if the server can deserialize the data.
The server will try to validate the `Content-Type` header against your configured `Content-Type` key from the config
96
-
file, and if the format is not supported, a status code `415 - Unsupported Media Type` will be returned.
83
+
The server will try to validate the `Content-Type` header against your configured `Content-Type` key from the config file, and if the format is not supported, a status code `415 - Unsupported Media Type` will be returned.
97
84
98
-
For example, if you have a route that needs a file to be uploaded, normally you will configure the `Content-Type` of
99
-
that route to be `multipart/form-data`. The above request will fail as the client send`application/json` as
85
+
For example, if you have a route that needs a file to be uploaded, normally you will configure the `Content-Type` of that route to be `multipart/form-data`.
86
+
The above request will fail because the client sends`application/json` as
100
87
`Content-Type`.
101
88
102
-
> If the request does not contain "Content-Type" header, that means that the server will try to deserialize the data as
103
-
> it can.
89
+
> If the request does not contain a "Content-Type" header, that means that the server will try to deserialize the data to the best of its abilities.
104
90
105
91
## The `Request <-> Response` validation
106
92
107
-
In addition to the validation described above, a third one is happening and is the last one: the server will check if
108
-
the request `Accept` header can really be returned by the response.
109
-
110
-
Through the way **Dotkernel API** is returning a response in handler, a content type is always set.
93
+
In addition to the validation described above, a third and last one occurs.
94
+
The server will check if the format in the `Accept` header for the request can be returned in the response.
111
95
112
-
This cannot be the case in any custom response but in any case the server will check what `Content-Type` the response is
113
-
returning and will try to validate that against the `Accept` header of the request.
96
+
The way **Dotkernel API** returns a response in handler means a content type is always set.
97
+
This cannot be the case in any custom response, but the server will always check the `Content-Type` for the response and will try to validate that against the `Accept` header of the request.
114
98
If the validation fails, a status code `406 - Not Acceptable` will be returned.
0 commit comments