Merge pull request #697 from zalando/scop-spelling-and-grammar

tfrauenstein · web-flow · commit cb0624b2bc12 · 2021-12-09T15:57:59.000+01:00
spelling and grammar fixes
diff --git a/chapters/general-guidelines.adoc b/chapters/general-guidelines.adoc
@@ -108,4 +108,4 @@ compatibility (<<176>> on how to replace).
 
 As we control these URLs, we ensure that their content is *durable* and
 *immutable*. This allows to define API specifications by using fragments
-published via this sources, as suggested in <<151>>.
+published via these sources, as suggested in <<151>>.
diff --git a/chapters/http-headers.adoc b/chapters/http-headers.adoc
@@ -282,7 +282,7 @@ components:
         string with enough entropy to avoid collisions.
 
         Idempotency keys expire after 24 hours. Clients are responsible to stay
-        within this limits, if they require idempotent behavior.
+        within this limit, if they require idempotent behavior.
 
       type: string
       format: uuid
@@ -467,7 +467,7 @@ The following formats are allowed:
 * Random unique string restricted to the character set `[a-zA-Z0-9/+_-=]` maximal of 128 characters.
 
 *Note:* If a legacy subsystem can only process `Flow-IDs` with a specific
-format or length, it must define this restrictions in its API specification,
+format or length, it must define this restriction in its API specification,
 and be generous and remove invalid characters or cut the length to the
 supported limit.
 
diff --git a/chapters/http-requests.adoc b/chapters/http-requests.adoc
@@ -180,7 +180,7 @@ forced by a <<106,backwards compatible change>>). In preference order:
 
 In practice {RFC-7396}[JSON Merge Patch] quickly turns out to be too limited,
 especially when trying to update single objects in large collections (as part
-of the resource). In this cases {RFC-6902}[JSON Patch] is more powerful
+of the resource). In this case {RFC-6902}[JSON Patch] is more powerful
 while still showing readable patch requests (see also
 http://erosb.github.io/post/json-patch-vs-merge-patch[JSON patch vs. merge]).
 JSON Patch supports changing of array elements identified via its index, but 
@@ -293,7 +293,7 @@ Request methods in RESTful services can be...
   returning the same response or status code.
 * [[cacheable, cacheable]]{RFC-cacheable} - to indicate that responses are
   allowed to be stored for future reuse. In general, requests to safe methods
-  are cachable, if it does not require a current or authoritative response
+  are cacheable, if it does not require a current or authoritative response
   from the server.
 
 *Note:* The above definitions, of _intended (side) effect_ allows the server
diff --git a/chapters/http-status-codes-and-errors.adoc b/chapters/http-status-codes-and-errors.adoc
@@ -62,7 +62,7 @@ web servers like Nginx, that we do not suggest to use).
 The most commonly used codes are best understood and listed below as subset of
 the official HTTP status codes and consistent with their semantics in the RFCs.
 We avoid less commonly used codes that easily create misconceptions due to
-less familar semantics and API specific interpretations.
+less familiar semantics and API specific interpretations.
 
 **Important:** As long as your HTTP status code usage is well covered by the
 semantic defined here, you should not describe it to avoid an overload with
@@ -238,7 +238,7 @@ about your request processing status or error situations.
 Some APIs are required to provide either _batch_ or _bulk_ requests using
 {POST} for performance reasons, i.e. for communication and processing
 efficiency. In this case services may be in need to signal multiple response
-codes for each part of an batch or bulk request. As HTTP does not provide
+codes for each part of a batch or bulk request. As HTTP does not provide
 proper guidance for handling batch/bulk requests and responses, we herewith
 define the following approach:
 
@@ -357,7 +357,7 @@ codes).
 *Note:* Clients must be robust and *not rely* on a Problem JSON object
 being returned, since (a) failure responses may be created by infrastructure
 components not aware of this guideline or (b) service may be unable to comply
-with this guidelines in certain error situations.
+with this guideline in certain error situations.
 
 *Hint:* The media type `application/problem+json` is often not implemented as
 a subset of `application/json` by libraries and services! Thus clients need to
diff --git a/chapters/meta-information.adoc b/chapters/meta-information.adoc
@@ -29,7 +29,7 @@ Semantic Versioning 2.0] rules `1` to `8` and `11` restricted to the format
 <MAJOR>.<MINOR>.<PATCH> for versions as follows:
 
 * Increment the **MAJOR** version when you make incompatible API changes
-after having aligned this changes with consumers,
+after having aligned the changes with consumers,
 * Increment the **MINOR** version when you add new functionality in a
 backwards-compatible manner, and
 * Optionally increment the **PATCH** version when you make
@@ -185,7 +185,7 @@ API Audience narrative (internal link)].
 == {MUST-SHOULD} use functional naming schema
 
 Functional naming is a powerful, yet easy way to align global resources as
-_host_, _permission_, and _event names_ within an the application landscape. It
+_host_, _permission_, and _event names_ within an application landscape. It
 helps to preserve uniqueness of names while giving readers meaningful context
 information about the addressed component. Besides, the most important aspect
 is, that it allows to keep APIs stable in the case of technical and
@@ -257,6 +257,6 @@ and *only* allowed for hostnames of <<219, component-internal>> APIs:
 
 *Exception:* There are legacy hostnames used for APIs with `external-partner` audience 
 which may not follow this rule due to backward compatibility constraints. 
-The API Linter maintains a whitelist for this exceptions (including e.g. 
+The API Linter maintains an allow-list for these exceptions (including e.g. 
 `api.merchants.zalando.com` and `api-sandbox.merchants.zalando.com`).
 
diff --git a/chapters/performance.adoc b/chapters/performance.adoc
@@ -177,7 +177,7 @@ GET /order/123?embed=(items) HTTP/1.1
 
 
 [#227]
-== {MUST} document cachable `GET`, `HEAD`, and `POST` endpoints
+== {MUST} document cacheable `GET`, `HEAD`, and `POST` endpoints
 
 Caching has to take many aspects into account, e.g. general <<cacheable,
 cacheability>> of response information, our guideline to protect endpoints
diff --git a/models/problem-1.0.1.yaml b/models/problem-1.0.1.yaml
@@ -7,7 +7,7 @@ Problem:
       description: >
         A URI reference that uniquely identifies the problem type only in the
         context of the provided API. Opposed to the specification in RFC-7807,
-        it is neither recommended to be dereferencable and point to a
+        it is neither recommended to be dereferenceable and point to a
         human-readable documentation nor globally unique for the problem type.
       default: 'about:blank'
       example: '/problem/connection-error'
