Web service standards: SOAP, REST, OData, and more
So far, we've covered the components of a web service, the messaging format and transport protocols. But in the eye of the developer, the development manager, and the IT professional,the real choice you end up making is in choosing a web service standard. The most common standards you might hear about are SOAP, Rest and Odata and you might hear a lot of debateabout which one is best. It can turn very quickly into an impassioned argument but it's best just to understand these terms and how they work as I previously described, SOAP is strictly speaking a message format.
An XML based markup language with a very specific set of tags, attributes and supported data types. The introduction of SOAP in the late 1990s Triggered the broad spread use of web services in all sorts of applications. And led to the new buzz phrase, Service Oriented Architecture or SOA. Microsoft led the charge in late 2000 with its SOAP Toolkit 1.0. And distinguised SOAP the message format From the underlying software, by giving it a cute name and acronym. Remote object proxy engine, meaning the developers were being asked to work with SOAP on a rope.
Developers who used SOAP based services, don't need to deal directly with the underlying XML messages. Instead they call functions, known as operations, that are defined by the service they're using. The resulting code in a client-side application can look almost exactly like a function they might call in their local client environment. The translation of outgoing requests and incoming responses is handled by the underlying SOAP library implementation.
Typically, you'll have one implementation on the client and one on the server. I'll dive into the technical details of SOAP in a later chapter of this course. But, its enough to say here, that in the early 2000s, SOAP was the dominant web services standard. Both client and server implementations were delivered for nearly all popular programming languages and application platforms, and web service repositories became commonplace.
You could easily look up a service use it freely, or sign up for a web service subscription and use it in your application. SOAP's major downside is in its verbocity. Its request and response messages are encoded in a plaint text XML with a lot of attributes and annotations and, as a result, its messages simply require more text than slimmer message formats, such as JSON.
Also, the engines that are required to do the creation and parsing of SOAP messages are of varying quality. And the developer has to trust the libraries to do the right thing, work efficiently and quickly and translate everything from XML to native data types and back again. For developers who like to know exactly what's happening at run-time this is all a little too high level. And so sometime in the mid 2000s much of the web services world started moving towhat are known as RESTful web services The term REST, which stands for Representational State Transfer, was defined around the same time as SOAP by a fellow named Roy Fielding, who was also one of the principal authors of the HTTP specification.
But REST took a bit longer to gain traction in the computing world. REST requirements are lighter weight than those of SOAP, and only require that such services use simple HTTP request response messaging. REST is an architecture, not a specific web service messaging format, and it's wrapped around the concept of HTTP methods or verbs. As I've previouslydescribed in HTTP not all requests are equal.
A get request is different from a post request. And put and delete requests can also have their own meaning. RESTful services can exploit these differences. Translating them into specific server side actions. All you need is a client that's capable of forming and sending the requests, which are typically in the form of URIs. Uniform Resource Identifiers. Unlike SOAP, RESTful services don't all use the same message format.
One service might return data in a XML based language such as RSS or Atom. Or in a custom XML language designed for a particular business process. Or for the sake of speed and efficient use of bandwidth. It might encode it's data in Java script object notation, JSON. There are other constraints and the REST standard. RESTful services are by definition stateless.Meaning that each request response conversation stands on its own.
Also for the sake of improving performance RESTful services can be cacheable. So if its server side resources don't have to be exercised on each and every request. Over the past half decade As developers have shifted their focus to building applications for mobile devices, such as cell phones and tablets, speed and message size have become critical factors in decided how to implement or select a web service. Mobile devices have less storage than desktop computers, and cell phone users pay by the megabyte for the bandwidth they consume.
Due to it's verbosity and resulting size, SOAP isn't well suited to the mobile world. Instead, web services using JSON message notation are increasingly popular in the mobile development world. But, SOAP's robust data typing and web service everything's deep set of standards relating to security. Interoperability and IT management continue to make it appealing for use in large scale computer environments. Where network bandwidth and storage aren't at so high a premium.
The third standard I'll cover in depth in this course, is named OData. OData is based on REST. And shares many of its characteristics. Just as with any RESTful architecture, you sendOData requests in the form of URIs, or Uniform Resource Identifiers. And get data back in a parsable form. But, like SOAP, OData has a strict set of formatting and element naming rules.As with SOAP based libraries, OData enabled software and libraries hide the nuts and bolts of serializing and de-serializing messages from the developer, making it, in many cases, easier to code.
And while the original OData specification Said that response messages would always be in the form of XML known as Atom. The more recent versions of OData allow developers to receive JSON formatted messages as well. While OData started as a Microsoft proprietary technology, its now open source and is supported by many languages and platforms. There are other standards and buzz words in the web services world that are worth knowing about.
These include XML-RPC for XML Remote Procedure Call. This is a standard that precedes itself which can encode fewer data type than SOAP. But it is also a little more slender than SOAP as well. There's UDDI, or U-D-D-I, Universal Description Discovery and Integration. And WSDL, or W-S-D-L, Web Service Description Language, which are used to describe SOAP-based services UDDI is used to make them discoverable.
And WSDL to make them usable. There's also WSDM. Web Services Distributed Management.A standard for managing and monitoring the status of other services. And there's the WS asterisk, or web services everything group of standards. There are literally dozens of these standards. They start with WS dash and then are followed by some words that describe what they do. These standards are managed by an organization named The Web Services Interoperability Organization.
Available at www.ws-i.org The web service standards describe XML based languages for managing business processes and transactions, security, reliability and management. In this course I'll focus on these three major standards, SOAP, REST and ODATA and mention some of the other standards along the way. And at the end of the course, I'll offer some resources for further investigation, so you can learn more about the standards that matter to you.