REST podcast clarification

I inadvertently used the term 'data type' while describing a service interface in the recent ThoughtWorks podcast on REST. I meant 'message' or more generally, the input expected by a service to carry out an action. I am painfully aware of the consequences of sharing data types between a service and its consumers. End of clarification.

Going off topic now, but I always meant to share this gem of an illustration on the 400 series of HTTP status codes (client error) by Adam Koford (converted to poster by Jesse Friedman)




If you are writing a RESTful service, do consider using this rich range of codes while communicating with service consumers.