Share article:

REST 101

If you’ve ever tried to retrieve data from Google maps or Twitter, chances are you interacted with a REST API. REST API was derived from the concept of REST which is a term that was defined in Roy Fielding’s Ph.D. thesis and is the acronym for REpresentative State Transfer. Today there are very few applications that don’t have a REST API. Github, Facebook, Instagram and thousands of other companies have adopted this architectural style. To give a simple definition, REST is an interface between systems using HTTP to obtain data and generate operations on those data in all possible formats, such as XML and JSON.

What makes REST REST?

I will probably need to write a separate blog post just to answer that question. I’ll try to sum up the key characteristics of REST and keep this section concise and high-level.

Client-server separation

Have you ever wondered what happens when you type in “” in the address bar of your browser? The quick answer is your browser (aka the client), using HTTP, sends out a GET request to some server. The Google server responds, and your browser receives the response, which is then rendered into the HTML page that you see. In this model, servers are the service or resource providers, while the clients act as the requesters of those resources. Keep in mind, your browser is not the only form of a client. Clients can come in a wide variety of forms including iOS applications, a raspberry pi or even an ATM machine.

Stateless interactions

The server should not store any communication state or in other words, it should remain stateless. Sessions should be stored entirely by the client which means the server does not remember anything about the client who uses the API. Another way of putting this is if the server receives two separate requests from the same client, it should not remember anything about the first request, by the time the second one comes through. Due to this, every request coming from the client should carry all the information necessary for an action to be performed by the server.

Uniform interface

A major part of having a uniform interface in a RESTful API is using HTTP to provide CRUD (create, read, update and delete) actions for our resources. To transfer data between the client and the server, REST applies specific actions by using the concept of HTTP verbs (POST, GET, PUT and DELETE) on the resources, provided they are identified with a URI. This makes it easier to obtain a uniform interface that systematises the process with the information.

HTTP Verbs describe the type of operation:

  • POST: Create a resource
  • GET: Retrieve a resource
  • PUT: Update a resource
  • DELETE: Delete a resource

As you can tell, each HTTP verb corresponds to a CRUD action. In REST APIs, we leverage these verbs to describe the types of operations we want to execute.

Benefits of REST

Separation between the client and the server.

REST entirely separates the client from the server. This can be quite advantageous especially when making developments. To elaborate, it improves the portability of the interface to other types of platforms, it increases the scalability of the projects and allows the different components of the application to be developed independently.

Reliability and scalability.

Since the client and server are separated, this allows the developer to scale the product without experiencing conflicts or issues. The developer can migrate to other servers or make database changes, provided the data from each request is sent correctly. This level of decoupling makes it easier to have the front-end and the back-end on different servers, and this makes the applications less fragile and more flexible to work with.

Simplicity and platform agnosticism.

A REST API always adapts to the type of syntax or platforms being used, which gives considerable freedom when changing or testing new environments within the development. With a REST API, you can have Java, PHP or Node.js or even GO servers. The only thing is that it is indispensable that the responses to the requests should always take place in the language used for the information exchange, typically XML or JSON.

Trade-offs of REST

Stateless is quite a useful concept but since all session data is handled by the client, what happens if you send a massive chunk of data in your request? Imagine an entire table from your database. This can be concerning. That’s one of the trade-offs here. By keeping the server stateless, you’re compromising by having to deal with larger payloads. The other major drawback of REST comes from its scope for misuse. A common misuse of REST is to expose the entire data structure via endpoints, which is both unnecessary and difficult to do securely. The ‘ideal’ approach is to expose the resources that are relevant to the part of the system, and gracefully return error status codes on any inconsistency.


REST can be incredibly useful for building large, scalable system and because it’s easily consumed by most of today’s web browsers, REST + JSON (the dynamic duo) has become the de facto technology for the majority of public APIs. REST APIs can sometimes be tricky to build but if done right, they can be a powerful and handy tool in your kit. Take a look at the range of REST APIs that the team at MessageMedia has built over here.