-1

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?

  • 2
    Related: General question about REST principles – Doc Brown Mar 31 at 12:55
  • whats your question? why not have the server side build the html rather than sending json and having javascript build the html? – Ewan Mar 31 at 13:01
  • @Ewan all web application is doing request and response, in fact, simple web app (without REST) can accept request then send a response with a format like JSON, XML, etc.. So why should I still use REST if I can already do that? – Maxim Cruz Mar 31 at 13:10
  • why wouldnt that be rest – Ewan Mar 31 at 13:14
  • 1
    I think you maybe have an odd defintion of "REST API" and that is the reason for your confusion – Ewan Mar 31 at 13:18
2

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.

0

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.

  • Actually my confusion about REST is because of WebAPI. I mean, why do we have to use WebAPI to implement REST if we can do POST, GET, PUT, DELETE, and POST /shop/order/12344 in simple ASP.Net MVC. But probably that confusion is because of my limited knowledge about REST. – Maxim Cruz Mar 31 at 15:18
  • Hmm, I never worked with ASP.Net, but I understand that WebAPI is some framework probably intented to make implementing REST APIs easier... Whether that worked out or not ;) Anyways, I guess that no one forces you to use it. You can always implement REST APIs just using the simplest POST/GET/... stuff. – fxnn Mar 31 at 15:54
  • @Maxim Cruz You can create RESTful service using WCF if you like WCF. As fxnn said, WebAPI and WebAPI 2 are two frameworks focussing on RESTful services, making them easier to write. If you use ASP.Net, WebAPI is probably the simplest way to go. – Sylvain Rodrigue Mar 31 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.