Page History

Representational State Transfer, from now on called REST, is actually not really a protocol, but merely a style of communication. Great advantages of having no protocol are simplicity, visibility and performance. A disadvantage is that the communication is not strictly defined, and therefore needs to be documented in a sufficient way. There is an attempt to standardize this communication, called Web Application Description Language (WADL), but it is not widely adopted.

Calling a REST service

Calling a REST service is done by URL. This means that all the information that the server needs, to process your request, is part of the URL (this is not entirely true due to HTTP headers, but close enough). Here is an example of a REST web service that allows you to receive live information on American airports:

httphttps://servicessoa.smext.faa.gov/asws/api/airport/status/IAD?format=xmlxlm

Go ahead, click on it to see what the current conditions at Washington Dulles Airport are. Your answer may look something like this:

...

Now, lets look again at the URL:

httphttps://servicessoa.smext.faa.gov/asws/api/airport/status/IAD?format=xml

...

• The first part is the location of the webservice (httphttps://servicessoa.smext.faa.gov)
• The next part is a fragment (/asws/api/airport/status/IAD). Fragments are used to supply information to the web service. This particular fragment indicates that you want to retrieve the airport status from the airport with code IAD. You can request information on a different airport by changing the URL, for example: httphttps://servicessoa.smext.faa.gov/asws/api/airport/status/JFK?format=xml.
• Everything after the '?' are arguments. They essentially are also just information for your request. In this example the argument determines the answer format. It was set to XML in the example above. Try a JSON format by following this URL: http://services.faa.gov/airport/status/JFK?format=json