Using Hypermedia to Your Advantage

Many developers are familiar with the task of making a request to a server and receiving a response. We’ve been performing the same task since before the PC even appeared on the scene. So, it’s hard to imagine that anything new has come up. Hypermedia is that new thing, but before we go to far, let me fill in a few details.

When working on the Web, these requests normally go through a Web service that relies on a technology such as SOAP or REST. The essential idea is always the same—send a request, receive a response to that request (even when the response is an error). Of course, the Web adds it’s own wrinkles to the process. For example, most Web services rely on text-based data transfers, rather than the binary transfers used in the past.

The problem with this request/response scenario is that it assumes that the Application Programming Interface (API) used to make the transfer of information happen is well-documented by the provider and also well-understood by the developer. Unfortunately, documentation is often poor and understanding is even poorer. Wouldn’t it be nice if along with the response to a request, a developer also received a list of things that the result allows. Hypermedia performs precisely that task. When you make a request to a service that provides hypermedia support, not only do you get the information you requested, but you also get a list of things you can do with that information.

Hypermedia has just started picking up steam in the last year, so it doesn’t appear in any of my current books (you can bet it will in the future). However, I recently wrote an article about it entitled, Working with Hypermedia APIs. The article provides you with a good overview of what hypermedia APIs can do for you, why they’re an important new way of working with services, and what you can expect from them. Still, hypermedia APIs are in their infancy and I’ll eventually need to provide additional information about them.

Precisely what I do depends on your response to the article and to this post. For example, it may eventually be a good idea to get into the design criteria for hypermedia APIs. On the other hand, it may be better to start with existing hypermedia API services so that you can better see how they work. I’d like to hear from you about your interest level in the topic so that I know how to proceed. Make sure you write me about hypermedia APIs at John@JohnMuellerBooks.com or provide a comment to this blog post.

 

Web Services and Protocols

A number of my books (such as HTML5 Programming with JavaScript For Dummies, Start Here! Learn Microsoft Visual C# 2010 Programming, Professional Windows 7 Development Guide, and LINQ for Dummies) discuss Web services and how to access them. As developers become more and more pressed for time, using code that has been debugged and tested by someone else becomes extremely tempting. Web services provide free or paid access to someone’s code in a specific manner. Using Web services is the only way that many organizations can deliver robust applications on time and within budget today. That’s the reason Web services figure prominently in previous books and will become even more important in upcoming books.

If every one of these Web services used a different set of low-level rules to provide access, it would be a nightmare for developers to access them. Fortunately, Web services generally use one of two methods of low-level access: Simple Object Access Protocol (SOAP) or REpresentational State Transfer (REST). Most developers assume that one or the other protocol is best, but a recent article that I wrote, “Understanding SOAP and REST Basics” points out that you actually need to be proficient with both protocols to get the most out of the resources available online. The overall point of this article is that a well-equipped developer can make things happen quickly by using the best Web service for a particular task, irregardless of the underlying protocols that it uses.

Web services still have many differences. In most cases, the differences are due to individual team perspectives of the task at hand, rather than some requirement for exposing the data in a certain way. A few of these differences are incredibly convoluted. Sending REST requests where you include data as part of the request header is one example of a needlessly cumbersome method of transferring information. The need to send every SOAP request as pure XML creates ticklish situations at times. Future standards (and there will be many) will help smooth these differences out and make Web service access even easier.

The use of Web services as a programming strategy is still in its infancy, so you should expect to see some major changes as more developers rely on Web services as a basic programming tool. What are some of the most pressing problems you see with SOAP and REST today? Do you feel there will be a third standard that marries the best features of the two standards and also adds a few features of its own? What sorts of Web services would you like to see in the future? Let me know your thoughts on the topic at John@JohnMuellerBooks.com.