> the "API specification" given to clients, in a truly RESTful system, should only be the initial entry point URI/URL I don't know that I fully agree? The conf

> the "API specification" given to clients, in a truly RESTful system, should only be the initial entry point URI/URL I don't know that I fully agree? The configuration, perhaps, but I think the API specification will be far more than just a URL. It'll need to detail whatever media types the system the API is for uses. (I.e., you'll need to spend a lot of words on the HTTP request/response bodies, essentially.) From your link: > A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state That. I.e., you're not just returning `application/json` to your application, you're returning `<something specific>+json`. (Unless you truly are working with JSON generically, but I don't think most are; the JSON is holding business specific data that the application needs to understand & work with.) That is, "and [the] set of standardized media types that are appropriate for the intended audience" is also crucial. (And I think this point gets lost in the popular discourse: it focuses on that initial entry URL, but the "describe the media types", as Fielding says, should be the bulk of the work — sort of the "rest of the owl" of the spec. There's a lot of work there, and I think sometimes people hearing "all you need is one URL" are right to wonder "but where's the rest of the specification?")