REST Design Principles

Everything is a Resource

• Everything that needs to be identified on web should be treated as Resource and be uniquely identified.
•  Resource is usually Noun and not verb
•  Each piece of data available on the Internet has a format that could be described by a content type
• Example: “http://Csharpstar.com/Employee/1234

Each resource is identifiable by a unique identifier (URI)

• The Internet contains so many different resources, they all should be accessible via URIs and should be identified uniquely
• The URI keeps the data self-descriptive and eases further development on it.
• The URIs helps you to reduce the risk of logical errors in your programs to a minimum.
• URIs expose different types of resources in a straightforward manner
• Example:

    – Images (http://Csharpstar.com/Images)  
    – Videos (http://Csharpstar.com/Videos)  
    – XML documents (http://Csharpstar.com/Archieves)

Use the standard HTTP methods

   Use standard Http methods to operate on identified resources
    – Get : Request an existing Resource
    – Post :Update an existing Resource
    – Put : Create or Update a Resource
    – Delete:Remove/Delete a Resource

Allow multiple representations for same Resource

•  A key feature of a resource is that they may be represented in a different form than the one it is stored. so, it can be requested or posted in different representations.As long as the specified format is supported, the REST-enabled endpoint should use it
• The resource should be presented to client in multiple formats as the client desire. The format can be anything like XML,JSON,JPG,PDF,HTML etc..

Communication should be always stateless   

• REST services are stateless by nature. So, the clients state can not be stored on the server.However, the client can still maintain state and pass it to the service with each request
• In a production environment, it is likely that incoming requests are served by a load balance, ensuring availability and high availability. Once exposed via a load balance, the idea of keeping your application state at server side gets compromised. This doesn’t mean that you are not allowed to keep the state of your application. It just means that you should keep it in a RESTful way.