You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Request/response rules and how to read their example renditions:
216
+
- All request headers, URL query-string parameters and response headers are identical over the whole set of all operations. Only request and response bodies are operation-specific.
217
+
- Request bodies **must never** be empty or the JSON ´null´: the empty request body is the JSON ´{}´.
218
+
- Response bodies will never be empty, but may be the JSON ´null´.
219
+
- All request fields are by default optional and ommittable / ´null´able, **any exceptions** to this are indicated by the operation's listed known-error responses.
220
+
- Example values rendered in this doc:
221
+
- ´true´ indicates any ´boolean´ value, regardless of the actual real value in a call
222
+
- ´"someStr"´ indicates any ´string´ value
223
+
- date-time values are indicated by RFC3339-formatted ´string´ examples
224
+
- signed-integer ´number´s are indicated by a negative-number example indicating the minimum (type-wise, not operation-specific) permissible value, with the maximum being the corresponding positive-number counterpart
225
+
- unsigned-integer ´number´s are indicated by a positive-number example indicating the maximum (type-wise, not not operation-specific) permissible value, with the minimum being ´0´
226
+
- floating-point ´number´s are indicated by a positive-number example indicating the maximum (type-wise, not not operation-specific) permissible value, with the minimum being the corresponding negative-number counterpart
227
+
228
+
More about error responses:
229
+
- All are ´text/plain´.
230
+
- In addition to those listed in this doc (thrown by the service under the indicated conditions), other error responses are always entirely possible and not exhaustively documentable feasibly (such as DB, file-system or network disruptions). Those caught by the service will be ´500´s, others (ie. from load-balancers / gateways / reverse-proxies etc. in front of the service) might have any HTTP status code.
231
+
- The well-known error responses listed here have been recursively determined by code-path walking. Among them are some that logically could not possibly ever occur for that operation, yet identifying those (to filter them out of the listing) is (so far) out of scope for our ´openapi.json´ generation.
232
+
- The well-known (thrown rather than caught) errors have their code-identifier-compatible (spaceless ASCII) enumerant-name as their entire text response, others preserve simply their original (usually human-language) error message fully. Hence, error responses are inherently ´switch/case´able.
0 commit comments