corrections & fresh build
BIN
docs/API.en.epub
BIN
docs/API.en.pdf
BIN
docs/API.ru.epub
BIN
docs/API.ru.pdf
@ -113,7 +113,7 @@
|
||||
<li><a href="API.en.html#http-api-rest-myth">Chapter 34. The REST Myth</a></li>
|
||||
<li><a href="API.en.html#http-api-requests-semantics">Chapter 35. Components of an HTTP Request and Their Semantics</a></li>
|
||||
<li><a href="API.en.html#http-api-pros-and-cons">Chapter 36. Advantages and Disadvantages of HTTP APIs</a></li>
|
||||
<li><a href="API.en.html#http-api-rest-organizing">Chapter 37. Organizing an HTTP API Based on the REST Principles</a></li>
|
||||
<li><a href="API.en.html#http-api-rest-organizing">Chapter 37. Organizing HTTP APIs Based on the REST Principles</a></li>
|
||||
<li><a href="API.en.html#chapter-38">Chapter 38. Working with HTTP API Errors</a></li>
|
||||
<li><a href="API.en.html#chapter-39">Chapter 39. Organizing the HTTP API Resources and Operations</a></li>
|
||||
<li><a href="API.en.html#chapter-40">Chapter 40. Final Provisions and General Recommendations</a></li>
|
||||
|
@ -1,4 +1,4 @@
|
||||
### [Organizing an HTTP API Based on the REST Principles][http-api-rest-organizing]
|
||||
### [Organizing HTTP APIs Based on the REST Principles][http-api-rest-organizing]
|
||||
|
||||
Now let's discuss the specifics: what does it mean exactly to “follow the protocol's semantics” and “develop applications in accordance with the REST architectural style”? Remember, we are talking about the following principles:
|
||||
* Operations must be stateless
|
||||
|
@ -3,7 +3,7 @@ sequenceDiagram
|
||||
participant D as Gateway D
|
||||
participant A as Authorization<br/>Service A
|
||||
participant B as User Profiles<br/>Service B
|
||||
participant C as Order<br/>Service C
|
||||
participant C as Orders<br/>Service C
|
||||
U->>+D: GET /v1/state<br/>Authorization: Bearer #60;token#62;
|
||||
par
|
||||
D->>+B: GET /v1/profile<br/><token>
|
||||
|
@ -3,7 +3,7 @@ sequenceDiagram
|
||||
participant D as Gateway D
|
||||
participant A as Authorization<br/>Service A
|
||||
participant B as User Profiles<br/>Service B
|
||||
participant C as Order<br/>Service C
|
||||
participant C as Orders<br/>Service C
|
||||
U->>+D: GET /v1/state<br/>Authorization: Bearer #60;token#62;
|
||||
D->>+A: GET /v1/auth<br/>#60;token#62;
|
||||
A-->>-D: { status, user_id }
|
||||
|
@ -3,7 +3,7 @@ sequenceDiagram
|
||||
participant D as Gateway D
|
||||
participant A as Authorization<br/>Service A
|
||||
participant B as User Profiles<br/>Service B
|
||||
participant C as Order<br/>Service C
|
||||
participant C as Orders<br/>Service C
|
||||
U->>+D: GET /v1/state<br/>Authorization: Bearer #60;token#62;
|
||||
D->>+A: GET /v1/auth<br/><token>
|
||||
A-->>-D: { status, user_id }
|
||||
|
@ -3,7 +3,7 @@ sequenceDiagram
|
||||
participant D as Gateway D
|
||||
participant A as Authorization<br/>Service A
|
||||
participant B as User Profiles<br/>Service B
|
||||
participant C as Order<br/>Service C
|
||||
participant C as Orders<br/>Service C
|
||||
U->>+D: POST /v1/orders HTTP/1.1<br/>If-Match: #60;revision#62;<br/>Authorization: Bearer #60;token#62;
|
||||
D->>+A: GET /v1/auth<br/><token>
|
||||
A-->>-D: { status, user_id }
|
||||
|
Before Width: | Height: | Size: 134 KiB After Width: | Height: | Size: 135 KiB |
Before Width: | Height: | Size: 102 KiB After Width: | Height: | Size: 102 KiB |
Before Width: | Height: | Size: 179 KiB After Width: | Height: | Size: 180 KiB |
Before Width: | Height: | Size: 153 KiB After Width: | Height: | Size: 153 KiB |
@ -235,7 +235,7 @@ module.exports = {
|
||||
aImg: ({ src, href, title, alt, l10n, className = 'img-wrapper' }) => {
|
||||
const fullTitle = escapeHtml(
|
||||
`${title}${title.at(-1).match(/[\.\?\!\)]/) ? ' ' : '. '} ${
|
||||
alt == 'PD' ? l10n.publicDomain : `${l10n.imageCredit}: ${alt}`
|
||||
alt == 'CTL' ? l10n.ctl : `${l10n.imageCredit}: ${alt}`
|
||||
}`
|
||||
);
|
||||
return `<div class="${escapeHtml(
|
||||
|