| Developing REST API per definition of REST cannot be done pragmatically in the way described, so you are going to screw a lot of people if they think this is the last word on REST. 1. REST is a hypermedia API that (somewhat) describes its own services by returning URLs to resources, etc. Most people don't understand what REST was meant to be that can drive how REST clients were meant to be developed. Some of the major players with "REST" APIs don't either. 2. REST does not have to be versioned if for internal use. I actually agree with the versioning part, however I've also been on two teams over the past 10 years that developed versioned APIs and neither time did versioning matter, because those APIs were for internal use. 3. This is not a RESTful requirement, but, practically, you shouldn't design an API that allows any querying of resources beyond what should be needed. This is because of the memory required for caching responses (in a large application), because it therefore can be an easy target for attacks (lets throw a bunch of query params on here... mwhahahahaha), and just because it opens up security holes. Be explicit in what is allowed in your code and your documentation. 4. The querying and filtering I see in this document is insufficient for some applications and interfaces. It didn't take us long to run into the limitation of the search functionality described in this document in our current REST API based app. |