You may have seen the Google Product Search and may have thought that it would be useful to include a customized version of the search into a website or application. Unfortunately, you can't just create a custom search engine based on the Product Search using Google's custom search creator.
So, how would you incorporate the Product Search into an application? The answer is to use the Google Base API. The API allows for you to call a feed and if you use the [item type:products] option it will use the Product Search data.
The API allows you to receive the feed in Atom, RSS and JSON formats. Google has also made it very easy by making a feed URL builder (you can access the builder here).
So, if you want to make an application using the Products Search now you can.
The Web Application Description Language--"WSDL for REST"--draft has been updated by Marc Hadley. The namespace has been changed to "http://wadl.dev.java.net/2009/02" to reflect the new draft, and other minor improvements over the Novemeber 2006 version have been incorporated. New and notable:
- The status attribute was moved from the representation element to the response element. The cardinality of the response element was changed from 0–1 to 0–many. The fault element was removed.
- Allow parameters at top level and parameter references to prevent repetition when a parameter is used in multiple places.
- A resource type element may now contain resource child elements.
- Allow multiple resources elements within an application.
If you're a RESTafarian who still believes in contract-first web services design, don't miss it. You can view the new draft here.
The Java API for RESTful Web Services, JAX-RS (also known as JSR-311), has been approved by the final ballot of the SE/EE Executive Committee.
JAX-RS allows you to use @GET, @POST, @PUT, @DELETE, and other annotations to describe RESTful style web services in a manner similar to the way that JAX-WS does for SOAP and WSDL-based web services.
The java.net project page for JSR-311 is here. The reference implementation is called the Jersey project, but other implementations exist in the Restlet framework, JBoss RESTeasy project, and Apache CXF project.
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.