Understanding RESTful web services

Question

I've been trying to understand how RESTful web services work and I've come up with a series of doubts and questions for which I have been unable to find an answer. First of all and to make sure I am correctly understanding what this is all about, the following diagram summarizes what a RESTful architecture for a small website could look like:

The first server basically contains a set of services identified by URL's. Those services obtain information from different databases and provide it to someone asking through a REST API (JSON) over http or https. On another server, a web application in an MVC style interacts with those services through their URL's upon user requests.

1. Is my understanding correct?
2. How do web applications such as facebook cope with the delays in getting responses when handling multiple services?
3. How does one make sure that only certain entities are allowed access to services (in this example, how does Server 1 authenticate Server 2)?
4. Is it common to use these kinds of architectures for mobile applications too?
5. When mixing this type of architecture with AJAX, are the AJAX calls done directly to the services or do they go through the main web application controller?

Answer 1

1. Yes, your understanding is correct. Although, some REST services can be accessed directly, without passing by the server 2.

2. Getting a response is a matter of milliseconds, especially when data centers are close to each other geographically (because indeed, speed of light matters). If we are talking about small web apps, the REST service and the app may be hosted on the same machine, which may mean that the time lost exchanging data is less than a millisecond.

3. There are several authentication mechanisms. For instance, Server 2 may use an API key which is unknown by other servers. Another possibility is to look at the IP address of the client, although usually, it is a better idea to have the same authentication mechanism for internal and external use.

4. Yes. REST services are used for mobile applications, desktop applications, embedded apps, etc.

5. REST services can be used directly. Passing them through another server (would it be Server 2 in your diagram, or Server 3) adds a layer of complexity, but may sometimes be a valid choice.

---

Note that in many cases, multiple servers are involved anyway. For instance, for a small but reliable website which has no REST services:

• The request to the home page of a website may be handled by a failover server (such as Nginx) which determines which one of two app servers should handle the request.

• The app server starts handling the request.

• This produces several log entries which are sent to a log server.

• Since data is required, database servers are solicited. If the first database server is down, the failover one is used.

See? Without any REST services, five machines were used to generate a response (not counting different switches and network devices which were passing the request and the response).

Answer 2

To echo what MainMan said, there are two different concepts at play here, REST and microservices.

Your diagram is a micro-service set up. You can do this with RESTful architecture, or with any other architecture. While micro-services and REST are often used together they are not the same thing.

REST is a way of thinking about communication between clients and servers in order to ensure loose coupling between client and server.

It is a different paradign to the more traditional Remote Procedure Call paradign where the client issues command to the server to carry out. With RPC the client has to be aware of what commands the server understands, which can change at work on the server evolves.

With a REST architecture you limit the communication between client and server simply to commands to transfer a representation of a piece of data. HTTP is a RESTful architeture and the only verbs in HTTP are GET, PUT, POST, DELETE etc.

As an example of the difference say your service is about photo editing. In a traditional RPC setup the client might issue the server a whole lot of commands to update a photo. The client might say "Ok, first blur the image, then rotate it, then crop it". The client has issued 3 commands to the server.

The problem with that is that it couples the client and server together, in that the client must know what commands the server understands. Say later you change the command from "blur" to "defocus". You have to update every single client. Or say a client wants to do a "blur" but the server it is talking to only has version 0.1 of the server code and doesn't understand "blur". You have to update the server every time a client wants to do something new.

In REST what happens is instead the client says "Ok server give me a copy of the photo". The client gets/downloads a copy of the photo and then carries out any number of changes client side.

The client then says "Ok, server store this new state of the photo".

All the client and servers need to know is commands to get and push back the data. HTTP is a REST protocol and if you look at the HTTP verbs they concern themselves only with the getting and putting of resources.

So REST isn't really anything to do with microservice architecture, but is instead a way of thinking about how your client and server are going to handle commands and data between each other.