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.