You've already forked The-API-Book
mirror of
https://github.com/twirl/The-API-Book.git
synced 2025-07-12 22:50:21 +02:00
Change en version
This commit is contained in:
@ -10,8 +10,7 @@ Let's take a look at the following example:
|
||||
|
||||
```json
|
||||
// Method description
|
||||
POST /v1/bucket/{id}/some-resource↵
|
||||
/{resource_id}
|
||||
POST /v1/buckets/{id}/some-resources/{resource_id}
|
||||
X-Idempotency-Token: <idempotency token>
|
||||
{
|
||||
…
|
||||
@ -50,4 +49,4 @@ Simplified notation might be used to avoid redundancies, like `POST /some-resour
|
||||
|
||||
We will use sentences like “`POST /v1/bucket/{id}/some-resource` method” (or simply “`bucket/some-resource` method,” “`some-resource`” method — if there are no other `some-resource`s in the chapter, so there is no ambiguity) to refer to such endpoint definitions.
|
||||
|
||||
Apart from HTTP API notation, we will employ C-style pseudocode, or, to be more precise, JavaScript-like or Python-like one since types are omitted. We assume such imperative structures are readable enough to skip detailed grammar explanations. HTTP API-like samples intend to illustrate the *contract*, i.e., how we would design an API. Samples in pseudocode are intended to illustrate how developers might work with the API in their code, or how we would implement SDKs based on the contract.
|
||||
Apart from HTTP API notation, we will employ C-style pseudocode, or, to be more precise, JavaScript-like or Python-like one since types are omitted. We assume such imperative structures are readable enough to skip detailed grammar explanations. HTTP API-like samples intend to illustrate the *contract*, i.e., how we would design an API. Samples in pseudocode are intended to illustrate how developers might work with the API in their code, or how we would implement SDKs based on the contract.
|
||||
|
Reference in New Issue
Block a user