1. Use uniform contracts to allow consumers to comply with the service requirements, make the service discoverable, loosely coupled and composable.
2. Use POST when you want to create a sub resource. Use POST when you want to update the state of a resource. PUT ensures that a resource or resource value remains unique while duplicate instances are possible when using POST.
3. Use DELETE when you no longer require the resource.
4. When using GET, consider caching the static data in the response. Request should not contain more than 4KB data as it may lead to “414 – Request_URI Too Long” error.
5. Endpoint URI may undergo changes. Use the native HTTP endpoint redirection capability to redirect a request to new URI. HTTp provides status codes such as 301 for “Moved Permanently” and 307 for “Temporary Redirect”
6. Choose the right granularity. A coarse grained service is not always reusable. At the same time, a finer grained service may not be good from performance perspective.
7. When defining URIs,
– use nouns
– use tokens (eg bearer) for authorization/ authentications
– keep the URIs short
– avoid using content type to retain abstraction
– use positional parameters in the query string.
8. A service should be backward compatible.
9. Standard Media types should be clearly specified in the contract. Client should provide valid formats in the “Accept”, “Accept-Language”, “Accept-Charset”, “Accept-Encoding” and “Content-Type” to avoid any interoperability issues. Let the server tell the client if a format is not supported using valid HTTP Code.
10. Use reliable messaging techniques like MQ for critical operations when a message lost due to network failure is unacceptable and message should be retried. While the retry mechanism can be implemented using REST, it should not become complex.