Packetizer
Web Services

See also these subsections:

Web Services Classification

In general, most people classify web services into three categories: REST, RPC, and those that are a hybrid between REST and RPC.

REST is a somewhat misunderstood concept and, quite frankly, for good reasons. Many people try to use REST in places where it is really not the best fit. So, there is "abuse" in terms of RESTful design, yet people call the solution REST. Of course, that leads to more confusion for the next person trying to understand the concept. But, in a nutshell, REST merely uses HTTP in a way that HTTP was intended to be used. That is a bit of hand-waving, so read the REST page for more details.

RPC ("Remote Procedure Call") is the term applied to the use of technologies like SOAP, though is could be any XML or other data format. In RPC-type systems, devices communicate in a client/server fashion where the client requests that the server perform some function and a response is returned. And, more often than not, that communication is over HTTP these days. But, calling it RPC seems a bit strange, really. After all, a DNS query has never been called RPC. If we were to change DNS to accept SOAP messages and provide SOAP responses, would we still call it RPC? In short, the name RPC is not really the best term and is a little dangerous, as it forces people to have a more limited view of inter-machine communication.

The last classification of services is a hybrid of REST and RPC. There is little to say about this, except that a little of both model is utilized. In any other setting, one might just call this a hack. Seriously. After all, if one does not implement something in the "right" way, isn't that usually called a hack?

And this leads us into the discussion on why we think the classification system we use today is too constraining. Some think that if it is not HTTP and XML, then it is not a "valid" web service. Oh, but then somebody defined JSON and suddenly that became OK. The point is there will always be changes in technology, so we should never take a narrow view of what defines a web service.

The Internet was not designed such that only port 80 (the HTTP port) exists. Every machine has 65,535 ports available for communicating "services" to utilize. Some are definitely much more popular (like port 80), but as soon as we all decide that any one port is "the only port" and the only way to design web services, we miss a tremendous opportunity to fully exploit the power of the Internet.

There are tons of applications on the Internet. There are literally millions of devices on the Internet and the number is constantly increasing. As time progresses, more and more devices will communicate directly with each other and to force every application to follow the same model, same protocol, and same data format is just plain wrong.

Web services should be about enabling the Internet with all kinds of services. Just as we have for years, we should "pick the right tool for the job." If that means REST, great. If that means XML over HTTP, no problem. If that means using yet-another-syntax over some obscure port, go for it! What is important is that applications that need to communicate have the wherewithal to communicate.

One reason why use of port 80 has gained so much popularity is that it allows one to communicate through NAT/FW devices much more easily. So, what people then do is run all kinds of services — even streaming audio and video — over HTTP! That is really an abuse. That is definitely a hack. It is very understandable to want to protect systems from attack from rogue users on the Internet, but pushing everything through port 80 is not the right solution to the problem. After all, what security is there in that? One could send a virus through port 80 and transmit sensitive corporate documents through port 80. There is really only the illusion of security. We really should address the security threats more intelligently.

Web services should be about application and device enablement. One may have a mobile phone that uses any number of services on the Internet. Further, those applications may not use what has historically been called RPC or REST. They might be entirely different, and definitely might not be client/server in nature. There are many communication systems that are really peer-to-peer in nature, and we do not mean those that are often used for pirating music. Rather, we refer to systems that communicate bi-directionally. These may not use REST or XML, but they are nonetheless services on the Internet.

Any two entities that communicate need to agree on a protocol. So, choose a protocol and do it carefully. Consider issues like scalability, interoperability, security, etc. But, do not immediately force yourself into a corner and assume that REST and RPC are the only legitimate means to define a protocol. They certainly do meet the needs of a large number of applications and logically make sense when using a web browser. But, we would certainly not use REST or RPC to build an artificial intelligence system that resides in a distributed manner across a plurality of network devices. There are better ways and, for such a complex system, HTTP might just be one of many tools such a system might use.

So, how do we classify a service that is designed optimally in order to meet a set of design requirements in order to enable communication that ultimately brings benefit to the human users of that service? Well, we just call it a web service or Internet service. There is no need to categorize it, as doing so immediately constrains one's thinking and the types of services that will be made available on the Internet.