From 49388bf5d61967c703083e9eaf54a802b0717190 Mon Sep 17 00:00:00 2001 From: Simeon Andreas Kepp Date: Sun, 19 Jul 2026 12:27:25 +0200 Subject: [PATCH] Fix inconsistent heading indentation (stray leading space) Four headings in README.md have a single leading space before the "###" ATX marker, unlike all other 99 headings in the document which start at column 0: - "MUST property names must be snake_case or camelCase [118]" - "MUST use same semantics for null and absent properties [123]" - "PUT" - "SHOULD use URL versioning [115]" GitHub's renderer tolerates up to 3 leading spaces on an ATX heading per CommonMark, so these still render correctly today - but the inconsistency shows up in stricter markdown linters/tooling and in diffs, and there's no reason for these four to differ from the other 99 headings in the same file. Purely whitespace, no wording changed. Co-authored-by: Laura Serna Gaviria --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 0238bda..d4b5012 100644 --- a/README.md +++ b/README.md @@ -500,7 +500,7 @@ Array names should be pluralized to indicate that they contain multiple values. } ``` - ### MUST property names must be snake_case or camelCase [118] +### MUST property names must be snake_case or camelCase [118] Property names are restricted to ASCII snake_case or camelCase. In an API the two casings must not be mixed. @@ -563,7 +563,7 @@ An actual JSON object described by this might then look like this: } } ``` - ### MUST use same semantics for null and absent properties [123] +### MUST use same semantics for null and absent properties [123] OpenAPI 3.x allows to mark properties as `required` and as `nullable` to specify whether properties may be absent (`{}`) or `null` (`{"example":null}`). If a property is defined to be not `required` and `nullable` (see 2nd row in Table below), this rule demands that both cases must be handled in the exact same manner by specification. @@ -628,7 +628,7 @@ paths: * `GET with body` the lengthy structured request information must not be encoded using header parameters. From a conceptual point of view, the semantic of an operation should always be expressed by the resource names, as well as the involved path and query parameters. In other words by everything that goes into the URL. Request headers are reserved for general context information. In addition, size limits on query parameters and headers are not reliable and depend on clients, gateways, server, and actual settings. Thus, switching to headers does not solve the original problem. - ### PUT +### PUT `PUT` requests are used to **update** (and sometimes to create) **entire** resources – single or collection resources. @@ -1338,7 +1338,7 @@ If changing an API can’t be done in a compatible way, then proceed in one of t As we discourage versioning by all means because of the manifold disadvantages, we strongly recommend to only use the first two approaches. - ### SHOULD use URL versioning [115] +### SHOULD use URL versioning [115] When API versioning is unavoidable you should design your multi-version RESTful APIs using URL versioning. With URL versioning a version is included in the path: