myRIZZEBookmarks

3. Add meta data to your responses. This probably breaks HATEOAS or some REST principle in that you expect the object and only the object in your response, but come on. Don’t you want your users to have easy access to errors, error codes, error messages, etc.? Sure you can pass that information in the header somehow, but I’ve seen clients who cannot figure out how to use the header responses correctly. It’s so easy to parse a JSON response. Why make it harder for your users? 4. Return a status and the object on POST and PUT calls. This might violate the tenants of REST, but users need to know when their calls work. Returning the object saves them from having to send a GET call on their end and you from having to handle their separate GET call. This is especially helpful in mobile app development. Who wants a slow mobile app? 5. Return the object type on a GET. By this I mean have your JSON for the banana service look something like ‘….”banana” : {“field1” : 13….}’ Sometimes users like to write generic parsers and it is easier if they can tell which object they are getting back from the response itself.