REST – Representational State Transfer

REST is a term coined by Roy Fielding to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.  It represents the state of database at a time. REST is an architectural style which is based on web-standards and the HTTP protocol. In a REST based architecture everything is a Resource. A resource is accessed via a common interface based on the HTTP standard methods. You typically have a REST server which provides access to the resources and a REST client which accesses and modifies the REST resources.  Every resource should support the HTTP common operations. Resources are identified by global IDs. REST allows that resources have different representations, e.g., text, XML, JSON etc.

HTTP Methods

The PUT, GET, POST and DELETE methods are typically used in REST based architectures. The following table gives an explanation of these operations:

POST –> INSERT (adds to an existing resource)

PUT –> UPDATE (overrides existing resource)

GET –> SELECT (fetches a resource, while the resource is never changed via a GET request)

DELETE –> DELETE (deletes a resource)



Purpose Method Incorrect Correct
Retrieves a list of users GET /getAllCars /users
Create a new user POST /createUser /users
Delete a user DELETE /deleteUser /users/1
Get balance of user GET /getUserBalance /users/1/balance


Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all resources.

/cars instead of /car

/users instead of /user

/products instead of /product



  • Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET method or Query parameters for state changes.
  • If a resource is related to another resource use sub resources.
  • Both, client and server need to know which format is used for the communication. The format has to be specified in the HTTP-Header.
  • Make the API Version mandatory and do not release an un versioned API.
  • Use a simple ordinal number and avoid dot notation such as 2.5
  • Use a unique query parameter for all fields or a query language for filtering.
  • Allow ascending and descending sorting over multiple fields.
  • Use limit and offset. It is flexible for the user and common in leading databases.
  • To make the API experience more pleasant for the average consumer, consider packaging up sets of conditions into easily accessible RESTful paths.



Thank you for your time!






Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s