The everyday use of the World Wide Web has produced the need for both web sites and web services.
Web sites are essentially data interpreted and displayed on a browser so that humans can read and interact with them. Web services on the other hand offer some service to a software application. It will generate a response when a request is sent, which can include data that will determine the result.
The returned response of a web service may or not be readable by humans, but that is not the main function as it is intended for software applications.
You may have created a great new site that recommends vacation spots to your visitors. The website itself is where a person could go to browse for information. The site might include a web service that automatically pulls a map from Google when someone types in an address, or perhaps even uses their current location to call a map.
So what are the typical realizations or protocols for web services? Many people may be familiar with SOAP (Simple Object Access protocol), an XML based protocol that is used in the implementation of a web service to exchange information. It usually relies on HTTP (Hypertext Transfer Protocol) or SMTP (Simple Mail Transfer Protocol).
The disadvantage of using SOAP is the verbose XML format, which makes it considerably slower. It relies on HTTP as a transfer protocol, while not using Web Service-Addressing or an enterprise service bus. The roles of the interacting parties are therefore fixed. Because of the verbose nature of the protocol, the REST architectural style has become more popular.
RESTful services can dramatically reduce the complexity of our communication by making the representation our only standard. This means that we do not have to give additional information about procedures (add, remove, etc.) but rather we can merely discuss the representation to achieve anything we want.
Let’s say you have a hangar, and it contains 3 helicopters, 2 private jets, and 4 fighter planes. If this hangar simulates the REST api, we can request the current state of the hangar by simply asking “state?”
The hangar would respond with “3 helicopters, 2 private jets, 4 fighter planes.” The hangar command center is basically transferring their state by a representation.
Now, say I wanted the hangar to add 3 helicopters. One way would be to directly tell them, “please add 3 helicopters to the hangar.” This however would not be an example of a REST transfer because this would be calling a direct procedure.
Instead, the REST way to do this would be to send the order, with “Hangar – 6 helicopters, 2 private jets, and 4 fighter planes.” The hangar command center would say “roger.” Then, if we requested the state of the hangar again, it would reply with “6 helicopters, 2 private jets, 4 fighter planes.”
REST enforces a client/server model, where the client is gaining information and acting on a set of resources managed by a server. All communication must be stateless and cachable. Implementations of this architecture is said to be RESTful. There is no “official” standard for RESTful APIs, because REST is an architectural style, unlike SOAP which is a protocol.
REST is simple and lightweight, but also language and platform independent. Understanding and implementation of RESTful services are becoming incredibly useful in today’s tech world.