1
0
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:
taksedo
2024-08-20 13:07:02 +03:00
committed by GitHub
parent 91b4660e1f
commit bdff710d73

View File

@ -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.