“A web service is any piece of software that makes itself available over the internet, sometimes through HTTP, and uses a standardized XML messaging system.”

What is HTTP?

HTTP means Hypertext Transfer Protocol. It is a stateless internet protocol meaning that there is no memory of any previous page actions or commands. Basically, nothing can be remembered between state changes through just HTTP, other things have to be done to allow for a more stateful experience. Basically, this is how the internet communicates from website to website and from client (the user) to server (the host, like google.com).

These are the HTTP request and response formats:

HTTP Request

<VERB> is one of the HTTP methods like GET, PUT, POST, DELETE, OPTIONS, etc

<URI> is the URI of the resource on which the operation is going to be performed

<HTTP Version> is the version of HTTP, generally “HTTP v1.1” .

<Request Header> contains the metadata as a collection of key-value pairs of headers and their values. These settings contain information about the message and its sender like client type, the formats client supports, format type of the message body, cache settings for the response, and a lot more information.

<Request Body> is the actual message content. In a RESTful service, that’s where the representations of resources sit in a message.

HTTP Response

The server returns <response code>, which contains the status of the request. This response code is generally the 3-digit HTTP status code. Status codes like 1XX (informational), 2XX (Success), 3XX (Redirection), 4XX (Client Error), 5XX (Server Error). I’d say these status codes are very important to know as a web developer in order to provide for a secure and reliable web service.

<Response Header> contains the metadata and settings about the response message.  Things like Content-Length, Content-Type, Cookies etc…

<Response Body> contains the representation if the request was successful. Things like the HTML document or JSON object

My professor for my Enterprise Web Applications class at UCSD likes to refer to these formats as the “Law of Three” in regards to HTTP.

These are two popular forms of web services that are used widely today. I will try to explain the basics of each, and then have the pages I used for resources at the bottom.

Now what do these mean? These request and responses are how the messages the internet communicates through are built. It’s kind of like asking a person a question (the request) and getting an answer back (the response) just in a bit more structured way which is universally understood by browsers and servers. You can see this in action by Inspecting a page (opening Developer Tools on Google Chrome) then clicking the Network tab (you might have to refresh after) then when you click on the responses, you can see the request and the response!

REST (REpresentational State Transfer)

“A service based on REST is a RESTful service.”

Almost every RESTful service uses HTTP as its underlying protocol. It is used in mobile applications, socials media sites, mashup tools and automated business processes. Interactions between servers and clients happens through a set of verbs (GET, POST, PUT, DELETE) on nouns (resources like JSON, XML documents, CSVs, and RSS).

RESTful services utilizes these verbs and interacts with URIs (Universal Resource Identifier) through the HTTP method explained above.

For example, reddit posts allow you to view the JSON responses of a certain page. One of my favorite subreddits is r/nba. If you go to https://www.reddit.com/r/nba.json, you will get the JSON response for the page. You can create a RESTful service that uses the GET verb to retrieve this JSON response and interact with it on your own web service!

I’m currently trying to use telnet to create a generic GET request to the service, but I am getting a 301 Moved Permanently status code. If someone can point me into the right direction to getting this that would be awesome!

SOAP (Simple Object Access Protocol)

From what I understand, SOAP creates a way of communication between client and server, just differently than REST. It allows for a standard of encryption between the two entities while creating a standard for developers to create services off of. SOAP allows for communication between different all major operating system platforms since all OS platforms support web protocols. Web protocols support usage of HTTP and XML, and SOAP specifies how the HTTP and XML are used.

SOAP has a more rigid set of messaging patterns while REST is more flexible. However, both have well established rules that everyone has agreed on.

SOAP communicates through XML which, depending on the programming language you are using, needs to be built for a request and then retrieved from a response. The XML holds information about the resource the user is accessing by first sending some type of function to a resource, then retrieving the output through the response resource. Knowing how the resource works depends on the documentation and the XML can vary throughout the resources.

Which to use and why?

No service is better than the other. There are multitudes of situations where one could be better than the other. 

Here are some important points as to why:

SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:

• Language, platform, and transport independent (REST requires use of HTTP). SOAP allows use on SMTP which is used by several email clients.
• Works well in distributed enterprise environments (REST assumes direct point-to-point communication). I’m guessing this could mean that if a web service has distributed services, a SOAP service could distribute the work to several different servers to perform work on a request whereas a RESTful service interacts one-to-one client to server and server to client.
• Standardized. There are more strict rules in using a SOAP service than a RESTful service.
• Provides significant pre-build extensibility in the form of the WS* standards
• Built-in error handling
• Automation when used with certain language products

REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:

• No expensive tools require to interact with the Web service
• Smaller learning curve. I’ve actually learned REST first and think it’s much easier than SOAP. Could be bias.
• Efficient (SOAP uses XML for all messages, REST can use smaller message formats like JSON)
• Fast (no extensive processing required)
• Closer to other Web technologies in design philosophy

Although I have worked with standardized RESTful specifications like http://www.jsonapi.org which standardizes a way to interact with JSON objects through use of RESTful services.

Below are the several links I used to compile this hopefully useful blog.

1. http://www.drdobbs.com/web-development/restful-web-services-a-tutorial/240169069
2. http://searchsoa.techtarget.com/definition/REST
3. http://searchsoa.techtarget.com/definition/SOAP
4. http://blog.smartbear.com/apis/understanding-soap-and-rest-basics
5. https://docs.oracle.com/cd/A97335_02/integrate.102/a90297/overview.htm#1007696
6. http://www.webopedia.com/TERM/H/HTTP.html
7. http://stackoverflow.com/questions/4913763/what-does-it-mean-when-they-say-http-is-stateless