I am designing a server application implementing the XCAP protocol (based on HTTP). Basically, an XCAP server stores a client's configuration data in XML format. The client (a PC application, a mobile handset or a browser) can manage this data through the web, by firing HTTP requests to the server. An example of such data can be buddy lists, which are stored on the server but can be modified or updated by remote clients.
One way this functionality can be achieved is through a web application. However, I would like to know if this can be implemented as a web service. Since I haven't worked on them, I am short of arguments for/against a web services implementation. Can anyone help me out here?
If your application provides an interface to client application through the http protocol (in contrast to providing a web interface to human users), it *is* a web service. The question then becomes whether you want to follow existing web service standards, or want to roll your own.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
To amplify the ideas a bit: there are 2 major schools of thought with respect to providing a service over the web. Unfortunately, one of those schools uses the term "web service" and it has almost become synonymous.
This first school is the "web service standard(s)" as mentioned above. It is based on WSDL, SOAP, and a suite of standards (e.g. WS-Security, WS-Transaction, etc) collectively known as "WS-*". It is hard to write a summary of this, but essentially it is a large, corporate-driven effort to achieve interoperability. Think "Corba over the web". One pro is that some major players are involved (e.g. IBM, BEA, etc). Another pro is that it is indeed standards-based. A con is that it is relatively complex and involves several layers of technology. SOAP, in particular, notoriously lost its "Simple" adjective (which was in the original acronym: Simple Object Acess Protocol).
The second school is REST: REpresentational State Transfer. It predates the web service standards but came to the fore when an academic wrote a PhD paper and coined some new terms. The idea here is that the HTTP actions (GET, POST, etc) can be used to create effective contracts between clients and server providers. The simplicity of REST is attractive to many, especially in the face of the bloated complexity of WS-*. The downside of REST is precisely that there _are no standards_ (hence, "roll your own"). Another downside is that there isn't a strong sense of "best practices" or dominant toolkits. (By contrast, Apache Axis is a popular toolkit for the WS-* camp).
To be honest, it's a tough call between the two, and probably dependent on your requirements and corporate culture. I recently attended a seminar where the speaker said that some major players (Google, and I think Amazon) were quietly discontinuing support for their SOAP-based APIs. He also quoted some large percentage of Amazon partners (I think) that use REST versus SOAP/WS-*.
hope this helps, Mike
ps. be sure to use wikipedia or this site to supplement the info on SOAP, REST, etc. Unfortunately I don't have time to provide a lot of links etc.