Why should I use REST API?

Question

I somehow get the point of REST API, like for example you want to get the list of customers to the database server, you have to request a GET method and the server will throw a response with a standard format like JSON, XML, etc.. If you want to create data, you have to request a POST method and the server will throw a response whether it is successful or not.

But aren't we always doing such kinds of things with simple web without REST API? The client-side (browser) will make a request, then the server will respond. So why do we need REST?

One important thing I see with REST API is that, using it, you can request and get a response with other applications, e.g. desktop application, Postman, etc.. But can't we do it with a simple web server?

Answer 1

I know it might be a dumb question or this is the right question to ask.

aren't we always doing such kinds of things with simple web without REST API? The client-side (browser) will make a request, then the server will response. So why do we need REST?

The simple web IS a REST API.

Which is to say, REST is an architectural style. The reference application is the world wide web itself.

The fact that you can use a web browser to

• Post questions on stackexchange
• Watch cat videos
• Update the configuration of your router
• Shop for books
• Bet on sports

And so on is all a reflection of the fact that we have a limited and well specified assortment of domain agnostic messages that we can pass around.

Here's a key idea, that may help

REST is intended for long-lived network-based applications that span multiple organizations.

The web works because Mozilla, Apache, Google, Microsoft, and so on all follow a bunch of publicly available standards.

Over the last thirty years, this has turned out to be a really effective way to build distributed information systems with human consumers.

For example, thirty years ago, to ask this question you would be on some bulletin board system or perhaps an NNTP client. The arrival of the web was a mass extinction event for a number of information systems.

But... while creating a website for human beings is (relatively) well understood, creating websites for machines is different. We don't need to worry about presentation, so we can use media-types with more efficient sizing/parsing, but we also need to be able to train the machines to extract the domain semantics from the messages, which is hard.

And, to be honest, it's a hard problem that doesn't necessarily align well with the problem that people are trying to solve. If I'm writing a client with a lifetime that is expected to span multiple server releases, then it is useful to have a REST API that allows me to access the javascript client for the currently active server.

But does the javascript code need be long lived too? -- RPC and more finely tuned messages may be a better choice.

Answer 2

Maybe your confusion lightens up a bit by looking at the difference between HTTP and REST. The former is a communication protocol, whereas the latter is a design principle. In detail:

• HTTP is a protocol used to transfer data on a TCP/IP connection between a client and a server. Yes, your web browser uses it, that's what it was invented for, and yes, in the last fifteen years it got more and more poular to implement APIs, where the client is no browser, but just about any piece of code.
• REST is a principle (or, as Wikipedia puts it, an architectural style) for designing such APIs. By far not everyone building a HTTP API also builds a REST API, though many people use these two terms synonymous.

So, I think it's clear that HTTP brings us the PUT, POST and GET. But what's behind REST?

It brings in some rules of how to design the API, so that we gain some positive effects. The best know rule might be that the API should be stateless, so that the server side may be scaled and changed more easily. The rule with the most visible effect might be to use paths to model resources (e.g. POST /shop/order/12344 instead of GET /do_update_order?id=12344), which brings in semantics, modularization and visibility.

Besides, much has been said about REST. Maybe Martin Fowler has a good introduction here.

So no, the browser doesn't use REST, and by using REST, you can gain several advantages, which might (or might not) fit your requirements.