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.