HTTP allows you to specify the return format right in the headers of the response, so that's a clue that a REST ought not to standardize it. About 95% of the s

HTTP allows you to specify the return format right in the headers of the response, so that's a clue that a REST ought not to standardize it. About 95% of the services I use (or write) just send the equivalent of key-value pairs back to the user. JSON is the best choice here. However, for other services, the best choice is to send back HTML fragments, XML, executable Javascript, or even image and graphics formats. The one thing I would like to see standardized is error handling. Too many service throw back 200 OK and then, in some custom way in the body of the response, tell you there was an error. This is like snatching defeat from the jaws of victory. However, neither is it really obvious how to return the right HTTP error status. If someone asks your web service for a map centered at 2000 longitude, -1000 latitude, what do you say? 404, no such map found? or do you say 409 Conflict, even though that was really designed for PUT mid-air collisions? There ought to be statuses that more clearly map to common REST service problems, like "request parameter out of bounds". A common return format to represent such errors would be great, too.