If you need a quick list of aspects for engineers to consider when building a ReST based system (the list is derived from Joe Gregorio's site), try this:
This review notes that nearly all services do not use hypermedia which I think is unfortunate but understandable. I've always had a problem resolving the desire to be flexible in allowing the internal data identifiers to be used in many situations and the desire to be trivally easy for clients to access other resources by simply using links - the mashup problem. One issue I have is that the server-side software that generates the representation might not know all the possible resources made available by sibling services. Think of a US postal zip-code - if you have a service that provides weather based on zip code, should that representation also be responsible for linking to all other services - either provided by your system or some other server - that could potentially take in a zip-code? My approach is to return both direct links to known resources (tagged appropriately) as well as the short-form of the identifier, the plain zip-code for example. Microformats sort of do this, but it's a style that isn't well applied by data services.
- How does the API use URLs to identify resources?
- What HTTP methods does the API support?
- What status codes are returned?
- How are users and applications authenticated to the API?
- Are resources linked to one another (use of hypermedia)?
- What data formats does the API support?
One comment I have on this review of RESTful services is the author mistakes "URL" for only the portion before the query terms. This results in judging these services to be less RESTful than they actually are. Use of query terms does not mean there is one 'controller' with parameters, it actually increases the number of addressable resources which is good.
No comments:
Post a Comment