So, to understand REST, let's first see what an API is.
Application Programming Interface
Say you're working on your next killer application; you have built a great, extremely easy to use and friendly store. Now, you want developers to build products on top of that. Well, so, what do you do?
Now, what you'll need is some sort of interface between your web services, and the developer; this is what an Application Programming Interface essentially is.
The question you're probably asking me is: so? I still didn't get the point.
Let me explain a couple of design paradigms which were followed while creating APIs back in the day.
Before explaining further, let me take a few example cases; essentially you want a developer to be able to:
get a product;
create and edit a product;
delete a product
get all products;
delete all products;
mass edit products;
transact some amount for a specific product.
Before REST, normal HTTP routes were used; SOAP was used with XML.
Simple Object Access Protocol
This was a very simple protocol which followed some really basic principles. To access objects, you'll need to communicate in a specific language (WSDL, if anyone's interested). The remarkable part here is that this was a protocol, so the user bad to do some very minimal (or no) setup.
The debate between SOAP vs. REST can be very eloquently put forward by the very famous quote:
The fool speaks, the wise man listens.
There is no point in a debate. It's better at some places, REST is better at some other.
If I get into the very specifics of WSDL, this will be a huge answer; be in its essence, it needed some update. Or so people say.
Representational State Transfer
Here, you have resources, and to access then, you have specific methods. Say you wanted to create a product, you'll use the POST HTTP verb at a specific URI. Let's have a look:
The response will be a HTTP code: 2xx for success, 5xx for server errors, 3xx for redirection, and 4xx for errors.
Here, the resource is products. The following HTTP verbs are used:
GET (/products) - gets all the products
GET (/products/123) - get the product with the ID 123
POST (/products) - creates a new product
POST (/products/123) - 404. You wouldn't want this.
PUT (/products) - 404 Nope.
PUT (/products/123) - update the product with the ID 123
DELETE (/products) - delete the entire collection
DELETE (/products/123) - delete the specific product
So, what you see here is that you can do a lot of things with just one route. The bad design pattern which was used before this was the verb-based design pattern. It went something like:
/create?type=product (POST). This was a pseudo-implementation of a REST interface. Not recommended.
In its very basic form, REST packed a lot of stuff in the state they came (URI + Method), and so was the preferred way. SOAP is also great for some use cases. Since it requires no, or very little, setup, it's great for Banks and some old systems.
REST ties you to HTTP, while SOAP just defines a protocol; use whatever you want with SOAP.
Well, this is just scratching the surface of a very, very wast field. If you want to clarify anything, as this surely is a little confusing, feel free to ask!
Shreyansh Pandey
node, coffee and everything in between
So, to understand REST, let's first see what an API is.
Application Programming Interface
Say you're working on your next killer application; you have built a great, extremely easy to use and friendly store. Now, you want developers to build products on top of that. Well, so, what do you do?
Now, what you'll need is some sort of interface between your web services, and the developer; this is what an Application Programming Interface essentially is.
The question you're probably asking me is: so? I still didn't get the point.
Let me explain a couple of design paradigms which were followed while creating APIs back in the day.
Before explaining further, let me take a few example cases; essentially you want a developer to be able to:
Before REST, normal HTTP routes were used; SOAP was used with XML.
Simple Object Access Protocol
This was a very simple protocol which followed some really basic principles. To access objects, you'll need to communicate in a specific language (WSDL, if anyone's interested). The remarkable part here is that this was a protocol, so the user bad to do some very minimal (or no) setup.
The debate between SOAP vs. REST can be very eloquently put forward by the very famous quote:
There is no point in a debate. It's better at some places, REST is better at some other.
If I get into the very specifics of WSDL, this will be a huge answer; be in its essence, it needed some update. Or so people say.
Representational State Transfer
Here, you have resources, and to access then, you have specific methods. Say you wanted to create a product, you'll use the POST HTTP verb at a specific URI. Let's have a look:
The response will be a HTTP code: 2xx for success, 5xx for server errors, 3xx for redirection, and 4xx for errors.
Here, the resource is products. The following HTTP verbs are used:
/products) - gets all the products/products/123) - get the product with the ID 123/products) - creates a new product/products/123) - 404. You wouldn't want this./products) - 404 Nope./products/123) - update the product with the ID 123/products) - delete the entire collection/products/123) - delete the specific productSo, what you see here is that you can do a lot of things with just one route. The bad design pattern which was used before this was the verb-based design pattern. It went something like:
/create?type=product(POST). This was a pseudo-implementation of a REST interface. Not recommended.In its very basic form, REST packed a lot of stuff in the state they came (URI + Method), and so was the preferred way. SOAP is also great for some use cases. Since it requires no, or very little, setup, it's great for Banks and some old systems.
REST ties you to HTTP, while SOAP just defines a protocol; use whatever you want with SOAP.
Well, this is just scratching the surface of a very, very wast field. If you want to clarify anything, as this surely is a little confusing, feel free to ask!
I hope this helps! :)