Re: <a href="https://johnholdun.com/apis/rest/" rel="nofollow">https://johnholdun.com/apis/rest/</a><p>> When I say “REST,” I don’t mean when to use GET vs. POST (although that’s also important). What I mean is that you should read Roy Fielding’s dissertation, Architectural Styles and
the Design of Network-based Software Architectures, where Representational State Transfer was coined. Not once in its definition does he mention HTTP verbs!<p>Something that I still don't understand, is how HATEOAS relates to OpenAPI spec. Quoting Roy T. Fielding himself (<a href="https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="nofollow">https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...</a>):<p>> API designers, please note the following rules before calling your creation a REST API:<p>> [...]<p>> A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling].<p>> [...]<p>> A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]<p>Wouldn't that mean that using OpenAPI spec automatically means something is not a REST API, but instead it's just an RPC?<p>Not saying that's good or bad, just contrasting this with OP's recommendation against using "an RPC-based interface" while also quoting Roy on REST.<p>(Edit: Added more context.)