Nowadays, creating a webservice can be fairly simple. Axis has finally got to a point where creating a SOAP interface requires the minimum amount of chicken slaughtering and dark incantations, and .NET makes it ridiculously easy (no wonder Java 6 is aping .NET-style ease of use(magpiebrain – Sun on Mustang (J2SE 6.0) – squaring up to .NET?) for webservices). Both Djano and Rails make it easy to create REST-style apps (Django’s URL’s are RESTful out of the box). The problem is creating a webservice shouldn’t simply be a case of placing a language-agnostic HTTP-based interface (be it REST, XMP-RPC or SOAP) in front of your application.
The word ‘service’ in webservice should represent more than the programmatic interface between the server and clients. It should represent a contract between two parties – the maintainer and user of the service – on more levels that what methods can be called, and what types are defined.
As a developer of a service you must be able to commit to (and document if required) a level of service – in terms of uptime, throughput and handling support. You need to have a versioning strategy that allows clients to not only test against new versions of your service, but also gives them time to upgrade once a new version goes live. You need to establish agreed communication channels between yourself and clients. This applies equally if the service is for use inside a team, a department, a company or even between businesses.
As a user you need to give the service some indication of current and future load – giving them a chance to scale if required, throttle your traffic, or look at optimising your current use. You also need to be proactive in testing against new versions of the webservice – not only so you migrate to the latest and greatest version as soon as possible, but also so you can aid the developers and feedback bugs.
As sappy as it sounds it’s about being nice to each other. Webservice developers need to understand that their service doesn’t exist in a vacum – sure your lives would be easier without users, but without them the would be no need for your service. Clients need to understand that the developers need your help to do their job. I’ve seen first hand what can happen when the communication between the two groups of people break down – and that within the same department. Understanding what is involved in creating and maintaining a webservice will make everyone’s lives easier.