From 34cb71d1e7013c323f18c680392d57f76f40648c Mon Sep 17 00:00:00 2001 From: tkrop Date: Tue, 12 Dec 2023 13:40:18 +0000 Subject: [PATCH] deploy: f0ec6a844829c6e327e52c9a8de64e1d367f84f7 --- index.html | 520 ++++++++++++++++++++++++++++++----------------------- 1 file changed, 300 insertions(+), 220 deletions(-) diff --git a/index.html b/index.html index cef1c065..d4316e5c 100644 --- a/index.html +++ b/index.html @@ -4314,15 +4314,15 @@

GET

@@ -4337,8 +4337,8 @@

GET with body paylo

APIs sometimes face the problem, that they have to provide extensive structured request information with GET, that may conflict with the size limits of clients, load-balancers, and servers. As we require APIs to be standard conform -(request body payload in GET must be ignored on server side), API designers have to check the -following two options:

+(request body payload in GET must be ignored on server side), API designers +have to check the following two options:

    @@ -4350,9 +4350,9 @@

    GET with body paylo single structured URL encoded string.

  1. -

    POST with body payload content: when a GET with URL encoded query parameters -is not possible, a POST request with body payload must be used, and explicitly -documented with a hint like in the following example:

    +

    POST with body payload content: when a GET with URL encoded query +parameters is not possible, a POST request with body payload must be used, +and explicitly documented with a hint like in the following example:

@@ -4362,8 +4362,9 @@

GET with body paylo /products: post: description: > - [GET with body payload](https://opensource.zalando.com/restful-api-guidelines/#get-with-body) - no resources created: - Returns all products matching the query passed as request input payload. + [GET with body payload](https://opensource.zalando.com/restful-api-guidelines/#get-with-body) + - no resources created: Returns all products matching the query passed + as request input payload. requestBody: required: true content: @@ -4384,10 +4385,10 @@

GET with body paylo

Hint: As GET with body is used to transport extensive query parameters, the cursor cannot any longer be used to encode the query filters in case of cursor-based pagination. As a consequence, it is best practice to -transport the query filters in the body payload, while using pagination links -containing the cursor that is only encoding the page position and direction. -To protect the pagination sequence the cursor may contain a hash over all -applied query filters (See also SHOULD use pagination links).

+transport the query filters in the body payload, while using pagination +links containing the cursor that is only encoding the page position and +direction. To protect the pagination sequence the cursor may contain a hash +over all applied query filters (See also SHOULD use pagination links).

@@ -4402,38 +4403,41 @@

PUT

  • PUT requests are usually applied to single resources, and not to collection -resources, as this would imply replacing the entire collection

    +resources, as this would imply replacing the entire collection.

  • PUT requests are usually robust against non-existence of resources by -implicitly creating the resource before updating

    +implicitly creating the resource before updating.

  • -

    on successful PUT requests, the server will replace the entire resource -addressed by the URL with the representation passed in the payload (subsequent -reads will deliver the same payload, plus possibly server-generated fields like modified_at)

    +

    On successful PUT requests, the server will replace the entire resource +addressed by the URL with the representation passed in the payload. +Subsequent reads will deliver the same payload, plus possibly +server-generated fields like modified_at.

  • -

    successful PUT requests return 200 or 204 (if the resource was updated - -with or without returning the resource), 201 (if the resource was created) -or 202 (if accepted and processed asynchronously).

    +

    Successful PUT requests return 200 or 204 (if the resource was updated — with or without returning the resource), 201 (if the resource was newly +created), and 202 (if the request was accepted for asynchronous +processing).

The updated/created resource may be returned as response payload. We recommend, -to not use it per default, but if the resource is enriched with server-generated -fields like version_number. You may also support client side steering (see MAY consider to support Prefer header to handle processing preferences).

+to not use it per default, but if the resource is enriched with +server-generated fields like version_number. You may also support client side +steering (see MAY consider to support Prefer header to handle processing preferences).

-

Important: It is good practice to keep the resource identifier management under -control of the service provider and not the client, and, hence, to prefer POST for -creation of (at least top-level) resources, and focus PUT on its usage for updates. -However, in situations where the identifier and all resource attributes -are under control of the client as input for the resource creation you should use -PUT and pass the resource identifier as URL path parameter. +

Important: It is good practice to keep the resource identifier management +under control of the service provider and not the client, and, hence, to prefer +POST for creation of (at least top-level) resources, and focus PUT on its +usage for updates. However, in situations where the identifier and all resource +attributes are under control of the client as input for the resource creation +you should use PUT and pass the resource identifier as URL path parameter. Putting the same resource twice is required to be idempotent and to result -in the same single resource instance (see MUST fulfill common method properties) without data duplication in case of repetition.

+in the same single resource instance (see MUST fulfill common method properties) without data duplication in +case of repetition.

Hint: To prevent unnoticed concurrent updates and duplicate creations when @@ -4449,32 +4453,43 @@

POST

collection resource endpoint, but other semantics on single resources endpoint are equally possible. The semantic for collection endpoints is best described as "please add the enclosed representation to the collection resource -identified by the URL". The semantic for single resource endpoints is best described -as "please execute the given well specified request on the resource identified -by the URL".

+identified by the URL". The semantic for single resource endpoints is best +described as "please execute the given well specified request on the resource +identified by the URL".

  • -

    on a successful POST request, the server will create one or multiple new -resources and provide their URI/URLs in the response

    +

    On a successful POST request, the server will create one or multiple new +resources, usually returning the resources or their URI/URLs in the response.

  • -

    successful POST requests return 200 or 204 (if the resource was updated - -with or without returning the resource), 201 (if the resource was created) -or 202 (if accepted and processed asynchronously).

    +

    For a single resource (tree) POST is expected to utilize the Location +header pointing to the URL of the newly created resource (tree) — with or +without returning the resource (tree).

    +
    • +
  • +

    For multiple resources POST may either return a collection of newly +created resources as served by the GET collection endpoint, or a bulk +response using the status code 207 (see also MUST use code 207 for batch or bulk requests).

    +
    • +
  • +

    Successful POST requests return 200 or 204 (if the resource was updated — with or without returning the resource), 201 (if the resource was newly +created), and 202 (if the request was accepted for asynchronous +processing).

-

Note: By using POST to create resources the resource ID must not be passed as -request input date by the client, but created and maintained by the service and -returned with the response payload.

+

Note: By using POST to create resources the resource ID must not be passed +as request input date by the client, but created and maintained by the service +and returned with the response payload.

-

Apart from resource creation, POST should be also used for scenarios that cannot -be covered by the other methods sufficiently. However, in such cases make sure to -document the fact that POST is used as a workaround (see e.g. GET with body).

+

Apart from resource creation, POST should be also used for scenarios that +cannot be covered by the other methods sufficiently. However, in such cases +make sure to document the fact that POST is used as a workaround (see e.g. +GET with body).

Hint: Posting the same resource twice is not required to be idempotent @@ -4487,57 +4502,57 @@

PATCH

PATCH method extends HTTP via RFC-5789 standard to update parts of the resource objects where e.g. in contrast to PUT only a specific subset -of resource fields should be changed. The set of changes is represented -in a format called a patch document passed as payload and identified by a -specific media type. The semantic is best -described as "please change the resource identified by the URL according to my -patch document". The syntax and semantics of the patch document is not -defined in RFC-5789 and must be described in the API specification -by using specific media types.

+of resource fields should be changed. The set of changes is represented in a +format called a patch document passed as payload and identified by a specific +media type. The semantic is best described as "please change the resource +identified by the URL according to my patch document". The syntax and +semantics of the patch document is not defined in RFC-5789 and must +be described in the API specification by using specific media types.

  • PATCH requests are usually applied to single resources as patching entire -collection is challenging

    +collection is challenging.

  • PATCH requests are usually not robust against non-existence of resource -instances

    +instances.

  • -

    on successful PATCH requests, the server will update parts of the resource -addressed by the URL as defined by the change request in the payload

    +

    On successful PATCH requests, the server will update parts of the resource +addressed by the URL as defined by the change request in the payload.

  • -

    successful PATCH requests return 200 or 204 (if the resource was updated - -with or without returning the resource).

    +

    Successful PATCH requests return 200 or 204 (if the resource was +updated — with or without returning the resource), and 202 (if the request +was accepted for asynchronous processing).

-

Note: since implementing PATCH correctly is a bit tricky, we strongly suggest -to choose one and only one of the following patterns per endpoint (unless -forced by a backwards compatible change). In preference order:

+

Note: since implementing PATCH correctly is a bit tricky, we strongly +suggest to choose one and only one of the following patterns per endpoint +(unless forced by a backwards compatible change). In preference order:

  1. -

    use PUT with complete objects to update a resource as long as feasible +

    Use PUT with complete objects to update a resource as long as feasible (i.e. do not use PATCH at all).

  2. -

    use PATCH with JSON Merge Patch standard, a +

    Use PATCH with JSON Merge Patch standard, a specialized media type application/merge-patch+json for partial resource representation to update parts of resource objects.

  3. -

    use PATCH with JSON Patch standard, a specialized media type +

    Use PATCH with JSON Patch standard, a specialized media type application/json-patch+json that includes instructions on how to change the resource.

  4. -

    use POST (with a proper description of what is happening) instead of +

    Use POST (with a proper description of what is happening) instead of PATCH, if the request does not modify the resource in a way defined by the semantics of the standard media types above.

    5. @@ -4546,8 +4561,8 @@

    PATCH

    In practice 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 case JSON Patch is more powerful -while still showing readable patch requests (see also +of the resource). In this case JSON Patch is more powerful while +still showing readable patch requests (see also JSON patch vs. merge). JSON Patch supports changing of array elements identified via its index, but not via (key) fields of the elements as typically needed for collections.

    @@ -4581,12 +4596,13 @@

    DELETE

    parameters on the collection resource (see DELETE with query parameters).

  5. -

    successful DELETE requests return 200 or 204 (if the resource was deleted - -with or without returning the resource).

    +

    Successful DELETE requests return 200 or 204 (if the resource was +deleted — with or without returning the resource), or 202 (if the request +was accepted for asynchronous processing).

  6. -

    failed DELETE requests will usually generate 404 (if the resource cannot -be found) or 410 (if the resource was already deleted before).

    +

    Failed DELETE requests will usually generate 404 (if the resource cannot +be found) or 410 (if the resource was already traceably deleted before).

    7. @@ -4665,7 +4681,7 @@

    OPTIONS

    • OPTIONS responses usually either return a comma separated list of methods -in the Allow header or as a structured list of link templates

      +in the Allow header or as a structured list of link templates.

@@ -4683,18 +4699,18 @@

MUST
  • -

    safe - the operation semantic is defined to be read-only, +

    safe — the operation semantic is defined to be read-only, meaning it must not have intended side effects, i.e. changes, to the server state.

  • -

    idempotent - the operation has the same +

    idempotent — the operation has the same intended effect on the server state, independently whether it is executed once or multiple times. Note: this does not require that the operation is returning the same response or status code.

  • -

    cacheable - to indicate that responses are +

    cacheable — to indicate that responses are allowed to be stored for future reuse. In general, requests to safe methods are cacheable, if it does not require a current or authoritative response from the server.

    @@ -4896,13 +4912,13 @@

    SH PUT and DELETE providing the same properties.

-

If you mainly aim to support safe retries, we suggest to apply conditional key and secondary key pattern before the Idempotency Key pattern.

+

If you mainly aim to support safe retries, we suggest to apply conditional key and secondary key pattern before the idempotency key pattern.

-

Note, like for PUT, successful POST or PATCH returns 200 or 204 (if the resource -was updated - with or without returning the resource), or 201 (if resource was created). -Hence, clients can differentiate successful robust repetition from resource created -server activity of idempotent POST.

+

Note: like for PUT, successful POST or PATCH returns 200 or 204 (if +the resource was updated — with or without returning the resource), or 201 +(if resource was created). Hence, clients can differentiate successful robust +repetition from resource created server activity of idempotent POST.

@@ -4935,37 +4951,38 @@

SH

MAY support asynchronous request processing

-

Typically REST APIs are designed as synchronous interfaces where all server-side -processing and state changes initiated by the call are finished before delivering -the result as response. However, in long running request processing situations -you may make use of asynchronous interface design with multiple calls: one for -initiating the asynchronous processing and subsequent ones for accessing the -processing status and/or result.

+

Typically REST APIs are designed as synchronous interfaces where all +server-side processing and state changes initiated by the call are finished +before delivering the result as response. However, in long running request +processing situations you may make use of asynchronous interface design with +multiple calls: one for initiating the asynchronous processing and subsequent +ones for accessing the processing status and/or result.

We recommend an API design that represents the asynchronous request processing -explicitly via a job resource that has a status and is different from the actual -business resource. For instance, POST /report-jobs returns HTTP status code 201 to -indicate successful initiation of asynchronous processing together with the job-id -passed in the response payload and/or via the URL of the Location header. -The job-id or Location URL then can be used to poll the processing status -via GET /report-jobs/id which returns HTTP status code 200 with job status and -optional report-id as response payload. Once returned with job status finished, -the report-id is provided and can be used to fetch the result via GET /reports/id -which returns 200 and the report object as response payload.

+explicitly via a job resource that has a status and is different from the +actual business resource. For instance, POST /report-jobs returns HTTP status +code 201 to indicate successful initiation of asynchronous processing +together with the job-id passed in the response payload and/or via the URL of +the Location header. The job-id or Location URL then can be used to poll +the processing status via GET /report-jobs/id which returns HTTP status +code 200 with job status and optional report-id as response payload. Once +returned with job status finished, the report-id is provided and can be used +to fetch the result via GET /reports/id which returns 200 and the report +object as response payload.

Alternatively, if you do not to follow the recommended practice of providing a -separate job resource, you may use POST /reports returning a status code 202 -together with the Location header to indicate successful initiation of the -asynchronous processing. The Location URL is used to fetch the report via +separate job resource, you may use POST /reports returning a status code +202 together with the Location header to indicate successful initiation of +the asynchronous processing. The Location URL is used to fetch the report via GET /reports/id which returns either 200 and the report resource or 202 without payload, if the asynchronous processing is still ongoing.

-

Hint: Do not use response code 204 or 404 instead of 202 here — it is -misleading since neither is the processing successfully finished, nor do we want to -suggest a client failure.

+

Hint: Do not use response code 204 or 404 instead of 202 here — it +is misleading since neither is the processing successfully finished, nor do we +want to suggest a client failure.

@@ -5044,10 +5061,9 @@

MUST

SHOULD design simple query languages using query parameters

-

We prefer the use of query parameters to describe resource-specific -query languages for the majority of APIs because it’s native to HTTP, -easy to extend and has an excellent implementation support in HTTP clients -and web frameworks.

+

We prefer the use of query parameters to describe resource-specific query +languages for the majority of APIs because it’s native to HTTP, easy to extend +and has an excellent implementation support in HTTP clients and web frameworks.

By simple query language we mean one or more name-value pairs that are combined @@ -5080,8 +5096,8 @@

SH
  1. -

    Consider using simple query language when API is built to be used -by others (external teams):

    +

    Consider using simple query language when API is built to be used by others +(external teams):

  2. -

    For internal usage or specific use case a more complex query language -can be used (such as price gt 10 or price[gt]=10 or price>10 etc.). -Also please consider following our guidance for designing complex -query languages with JSON.

    +

    For internal usage or specific use case a more complex query language can be +used (such as price gt 10 or price[gt]=10 or price>10 etc.). Also +please consider following our guidance for designing complex query +languages with JSON.

@@ -5141,10 +5157,10 @@

Less than

  • -

    max_length=5 - query elements based on upper/lower bounds (min and max)

    +

    max_length=5 — query elements based on upper/lower bounds (min and max)

  • -

    shorter_than=5 - query elements using terminology specific e.g. to length

    +

    shorter_than=5 — query elements using terminology specific e.g. to length

  • price_lower_than=50 or price_lower_than_or_equal=50

    @@ -5167,7 +5183,7 @@

    More than

    • -

      min_length=2 - query elements based on upper/lower bounds (min and max)

      +

      min_length=2 — query elements based on upper/lower bounds (min and max)

    • created_after=2019-07-17 or modified_since=2019-07-17

      @@ -5212,8 +5228,8 @@

      Pagination

      and you can also find additional info in REST Design - Pagination section below.

    -

    We don’t advocate for or against certain names because in the end -APIs should be free to choose the terminology that fits their domain the best.

    +

    We don’t advocate for or against certain names because in the end APIs should +be free to choose the terminology that fits their domain the best.

@@ -5246,8 +5262,8 @@

SH

-

APIs that qualify for a specific, complex query language are encouraged to -use nested JSON data structures and define them using OpenAPI directly. The +

APIs that qualify for a specific, complex query language are encouraged to use +nested JSON data structures and define them using OpenAPI directly. The provides the following benefits:

@@ -5332,7 +5348,8 @@

Example

-
404 Not found RFC do not document <all>
+
404 Not found RFC use do not document <all>
-

The target resource was not found. This will be returned by most (not documented) paths on most -APIs, and for endpoints with parameters when those parameters don’t map to an -existing entity. For a PUT endpoint which only supports updating existing -resources, this might be returned if the resource does not exist. Apart from -these special cases, this does not need to be documented.

+

The target resource was not found. This will be returned by most paths on most +APIs (with out being documented), and for endpoints with parameters when those +parameters cannot be map to an existing entity. For a PUT endpoint which only +supports updating existing resources, this might be returned if the resource +does not exist. Apart from these special cases, this does not need to be +documented.

405 Method Not Allowed RFC document <all>

The request method is not supported for this resource. In theory, this can be -returned for all resources for all the methods except the ones documented. Using -this response code for an existing endpoint (usually with path parameter) only -makes sense if it depends on some internal resource state whether a specific -method is allowed, e.g. an order can only be canceled via DELETE until the -shipment leaves the warehouse. Do not use it unless you have such a special use -case, but then make sure to document it, making it clear why a resource might -not support a method.

+returned for all resources for all the methods except the ones documented. +Using this response code for an existing endpoint (usually with path +parameters) only makes sense if it depends on some internal resource state +whether a specific method is allowed, e.g. an order can only be canceled via +DELETE until the shipment leaves the warehouse. Do not use it unless you +have such a special use case, but then make sure to document it, making it +clear why a resource might not support a method.

-
406 Not Acceptable RFC do not document <all>
+
406 Not Acceptable RFC use do not document <all>
-

Resource only supports generating content with content-types that are not listed -in the Accept header sent in the request.

+

Resource only supports generating content with content-types that are not +listed in the Accept header sent in the request.

@@ -5722,16 +5741,16 @@
409 Conflict MUST be documented. For successful robust creation of resources (PUT or POST) you should always -return 200 or 204 and not 409, even if the resource exists already. If any -If-* headers cause a conflict, you should use 412 and not 409. Only +return 200 or 204 and not 409, even if the resource exists already. If +any If-* headers cause a conflict, you should use 412 and not 409. Only applicable to methods which change something.

410 Gone RFC do not document <all>
-

The resource does not exist any longer (but did exist in the past), and will -most likely not exist in the future. This can be used e.g. when accessing a +

The resource does not exist any longer. It did exist in the past, and will +most likely not exist in the future. This can be used, e.g. when accessing a resource that has intentionally been deleted. This normally does not need to be documented, unless there is a specific need to distinguish this case from the normal 404.

@@ -5740,25 +5759,25 @@
410 Gone
411 Length Required RFC document POST PUT PATCH
-

The server requires a Content-Length header for this request. This is normally -only relevant for large media uploads. The corresponding header parameter should -be marked as required. If used, it MUST to be documented (and explained). Only -applicable for methods with a request body.

+

The server requires a Content-Length header for this request. This is +normally only relevant for large media uploads. The corresponding header +parameter should be marked as required. If used, it MUST to be documented +(and explained).

-
412 Precondition Failed RFC do not document PUT PATCH DELETE
+
412 Precondition Failed RFC use do not document PUT PATCH DELETE
-

Returned for conditional requests, e.g. If-Match if the condition failed. Used -for optimistic locking. Normally only applicable to methods that change +

Returned for conditional requests, e.g. If-Match if the condition failed. +Used for optimistic locking. Normally only applicable to methods that change something. For HEAD/GET requests, use 304 instead.

-
415 Unsupported Media Type RFC do not document POST PUT PATCH
+
415 Unsupported Media Type RFC use do not document POST PUT PATCH
-

The client did not provide a supported content-type for the request body. -Only applicable to methods with a request body.

+

The client did not provide a supported content-type for the request body. Only +applicable to methods with a request body.

@@ -5785,19 +5804,27 @@
422 Unprocessab and there does not seem to be a clear benefit to differentiating between them.

-
-
423 Locked RFC PUT PATCH DELETE
+
+
423 Locked RFC document PUT PATCH DELETE
-

Pessimistic locking, e.g. processing states.

+

Pessimistic locking, e.g. processing states. May be used to indicate an +existing resource lock, however, we recommend using optimistic locking instead. +If used, it must be documented to indicate pessimistic locking.

+
+
+
+
424 Failed Dependency RFC do not use <all>
+
+

The request failed due to failure of a previous request. This is not applicable +to restful APIs.

-
428 Precondition Required RFC do not document <all>
+
428 Precondition Required RFC use do not document <all>

Server requires the request to be conditional, e.g. to make sure that the "lost -update problem" is avoided (see MAY consider to support ETag together with If-Match/If-None-Match header). Instead of documenting this -response status, the required headers should be documented (and marked -as required).

+update problem" is avoided (see MAY consider to support ETag together with If-Match/If-None-Match header). Instead of documenting this response +status, the required headers should be documented (and marked as required).

@@ -5807,30 +5834,81 @@
429 Too many re requests (see MUST use code 429 with headers for rate limits).

+
+
431 Request Header Fields Too Large RFC do not document <all>
+
+

The server is not able to process the request because the request headers are +too large. Usually used by gateways and proxies with memory limits.

+
+

Server side error codes

-
500 Internal Server Error RFC do not document <all>
+
500 Internal Server Error RFC use do not document <all>
-

A generic error indication for an unexpected server -execution problem (here, client retry may be sensible)

+

A generic error indication for an unexpected server execution problem. Clients +should be careful with retrying on this response, since the nature of the +problem is unknown and must be expected to continue.

-
501 Not Implemented RFC <all>
+
501 Not Implemented RFC document <all>
-

Server cannot fulfill the request (usually implies future -availability, e.g. new feature).

+

Server cannot fulfill the request, since the endpoint is not implemented yet. +Usually this implies future availability, but retrying now is not recommended. +May be documented on endpoints that are planned to be implemented in the +future to indicate that they are still not available.

-
503 Service Unavailable RFC do not document <all>
+
502 Bad Gateway RFC <all>
+
+

[.indent]is meaningless +The server, while acting as a gateway or proxy, received an invalid response +from an inbound server attempting to fulfill the request. May be used by a +server to indicate that an inbound service is creating an unexpected result +instead of 500. Clients should be careful with retrying on this response, +since the nature of the problem is unknown and must be expected to continue.

+
+
+
+
503 Service Unavailable RFC use do not document <all>
+
+

Service is (temporarily) not available, e.g. if a required component or inbound +service is not available. Client are encouraged to retry requests following an +exponential back off pattern. If possible, the service should indicate how long +the client should wait by setting the Retry-After header.

+
+
+
+
504 Gateway Timeout RFC use <all>
-

Service is (temporarily) not available (e.g. if a -required component or downstream service is not available) — client retry may -be sensible. If possible, the service should indicate how long the client -should wait by setting the Retry-After header.

+

The server, while acting as a gateway or proxy, did not receive a timely +response. May be used by servers to indicate that an inbound service cannot +process the request fast enough. Client may retry the request immediately +exactly once, to check whether warming up the service solved the problem.

+
+
+
+
505 HTTP Version Not Supported RFC do not use <all>
+
+

The server does not support the HTTP protocol version used in the request. +Technical response code that serves not use case in RESTful APIs.

+
+
+
+
507 Insufficient Storage RFC do not document POST PUT PATCH
+
+

The server is unable to store the resource as needed to complete the request. +May be used to indicate that the server is out of disk space.

+
+
+
+
511 Network Authentication Required RFC do not use <all>
+
+

The client needs to authenticate to gain network access. Technical response +code that serves no use case in RESTful APIs.

@@ -5972,7 +6050,7 @@

MUST needs. Retry-After is often sufficient for general load handling and request throttling scenarios and notably, does not strictly require the concept of a calling entity such as a tenant or named account. In turn -this allows resource owners to minimise the amount of state they have to +this allows resource owners to minimize the amount of state they have to carry with respect to client requests. The 'X-RateLimit' headers are suitable for scenarios where clients are associated with pre-existing account or tenancy structures. 'X-RateLimit' headers are generally @@ -6060,7 +6138,9 @@

MUST

Hint: The use of absolute URIs is not forbidden but strongly discouraged. If you use absolute URIs, -please reference problem-1.0.0.yaml#/Problem instead.

+please reference +problem-1.0.0.yaml#/Problem +instead.

@@ -6083,8 +6163,8 @@

SH
  1. -

    Changing the clients to use the new location in the first place, avoiding the -need for redirection.

    +

    Changing the clients to use the new location in the first place, avoiding +the need for redirection.

  2. Redirecting the traffic behind the API layer (e.g. in the reverse proxy or @@ -10817,7 +10897,7 @@

    Rule Changes