In fact, RESTful web services are not the only type of web services that we can write. There are other ways to write web services as well. There are old ways of writing web services as well as some more recent ways. We will not go in to detail about other web services, as that is out of the scope of the book, with the focus here being on RESTful web services and how to build them.
Why RESTful web services?
REST versus SOAP
One old alternative to REST is SOAP. In fact, SOAP was already, used when REST came along as an alternative. A key difference is that SOAP doesn't have some particular convention that tells consumers how to access that. SOAP exposes its services using WSDL. Consider WSDL as a definition of services that SOAP provides. This is how the consumer knows what SOAP based web service provides and how to consume them.
On the other hand, REST emphasizes on "conventions over configurations
". If you look at the URL structures and HTTP verbs of RESTful web services as we did earlier, there is a fixed convention. For example, if you are at the client side and want to create a product, if you know what parameters it will take then you can simply create it by sending a POST request to example.com/product and the resource will be created. If you want to list all the products, you can use the same URL with a GET request. If you get product IDs from the List operation, you can simply use them to update or delete a product by using example.com/product/{product_id} using PATCH and PUT or DELETE respectively. It is that simple to know what URL and HTTP method to use to do a type of operation because these are some conventions that RESTful web services follow. So, the one on the client end will just follow those conventions and will not need large documentations for simple tasks.
Other than that, simplicity of statelessness, separation of concerns, and cache-ability are some of the other advantages of RESTful web services that we have already seen in detail.