Web Services

In an attempt to beef up its ad-search business by opening up its search technology, Yahoo has launched a new program called BOSS (Build your Own Search Service). The move is part of the new "Yahoo Open Strategy", a strategy that aims to attract more users and developers to Yahoo's technology and services by opening them up. It's not a totally free lunch, of course, as traffic over a certain "query threshold" will require some type of agreement with Yahoo, either hosted ads, revenue, or some type of exclusivity agreement.

With this first release of BOSS developers can fetch search content for Web, News, Image, and Spelling Suggestions. The API itself is a RESTful web service, with the option to receive data back from the service in JSON or XML formats. Full documentation on the search API is here.

Part 1 of this series talks about SOAP vs. REST. In this installment I'll discuss the reasons for defining the web service contract between client and server, the existing methods for doing it, and the important concepts of each.

Defining the Contract

An important part of any web service is the contract (or interface) which it defines between the service and any clients that might use it. This is important for a number of reasons: visualization with tools, interaction with other specifications (e.g., web service choreography), code generation, and enforcing a high-level agreement between the client and service provided (that still gives the service freedom to change the underlying implementation). Taken together, they give pretty compelling use cases for having web services contracts, although advocates of minimalism may disagree.

When IBM, Microsoft, and Ariba submitted WSDL 1.1 to the W3C in 2001 as a language for describing web services in conjunction with SOAP 1.1, HTTP POST and GET, and MIME, it quickly became a standard used by every SOAP toolkit. This happened in spite of the fact that it never progressed beyond being a W3C Note (which, according to W3C, is a document available for "discussion" and not officially endorsed by the W3C). In fact, though there is both a WSDL 1.1 and 1.2, WSDL 2.0 is the only version of the specification officially endorsed by the W3C.

With the rise in popularity of RESTful web services, there also became a need to describe contracts for these types of web services as well. Although WSDL 2.0 attempts to fill the gap by providing support for HTTP binding, another specification fills this need in an arguably better way: WADL , a specification developed at Sun by Marc Hadley. Though it has not been submitted to any official standards body (OASIS, W3C, etc.), WADL is promising because of its more comprehensive support for REST-style services.

Developers new to web services are often intimidated by parade of technologies and concepts required to understand it: REST, SOAP, WSDL, XML Schema, Relax NG, UDDI, MTOM, XOP, WS-I, WS-Security, WS-Addressing, WS-Policy, and a host of other WS-* specifications that seem to multiply like rabbits. Add to that the Java specifications, such as JAX-WS, JAX-RPC, SAAJ, etc. and the conceptual weight begins to become heavy indeed. In this series of articles I hope to shed some light on the dark corners of web services and help navigate the sea of alphabet soup (1). Along the way I'll also cover some tools for developing web services, and create a simple Web Service as an example. In this article I will give a high-level overview of both SOAP and REST.