You might not be HATEOAS if...
There's been a lot of talk around the office and online lately about what HATEOAS actually means and how to actually implement it, so far I'm still not sure HOW to properly do HATEOAS, but I think the easiest way is to catalogue the various ways to NOT do HATEOAS:
- #youmightnotbehateoas if your resource representations don't include any form of link information
- #youmightnotbehateoas if your API blindly assumes you can PUT back what you GET, where you got it from
- #youmightnotbehateoas if your client developers refer to server source code for resource details
- #youmightnotbehateoas if your API sends/receives plain application/json or text/xml rather than application specific media types
- #youmightnotbehateoas if you or your API has a WADL file
- #youmightnotbehateoas if your URI's include version references
Comments like this (from the author of one of the referenced java.net articles) makes me think I simply do not want to do HATEOS anyway: "Certainly a service invocation can itself trigger a workflow, but that workflow must be finished before the call returns, since RESTful services must be stateless." Requiring that all workflows be synchronous with client actions means that 90% of what I consider interesting cannot be represented via HATEOS.
Q: why not application/json? I'm absolutely in agreement with not using text/xml (because of the encoding issues around it), but what's the alternative to application/json? A MIME type for every class of json object/"schema"? If so, to what end?