Is it typical for a provider of a web services to also provide client libraries?

Question

My company is building a corporate Java web-app and we are leaning towards using GWT-RPC as the client-server protocol for performance reasons. However, in the future, we will need to provide an API for other enterprise systems to access our data as well. For this, we were thinking of a SOAP based web service. In my experience it is common for commercial providers of enterprise web applications to provide client libraries (Java, .NET, C#, etc.).

Is this generally the case?

I ask because if so, then why bother using SOAP or REST or any standard web services protocol at all? Why not just create a client libraries that communicate via GWT-RPC?

Answer 1

Don't use GWT-RPC for "open APIs": a client would break as soon as you change a class on your server.

RequestFactory could be an option though, as you can use ServiceLayerDecorator to provide a "migration path" for old clients when you update your server (plus, you won't break a client if you change your server classes but not your proxies, and even if you change your contexts or proxies, you'll only break clients if you made, er, breaking changes to them), and a Java client is built-in (RequestFactorySource with UrlRequestTransport)

That being said, if you really want an "open API", then go the "REST" road. Using things like JAX-RS or Restlet, you can leverage the code you wrote for your GWT app (using GWT-RPC or RequestFactory).

Answer 2

It depends on the clients needs for the web-app. Two common scenarios are clients with little or no IT resources, and clients who have their IT teams working on a larger overall project.

Providing client libraries helps with adoption. Typically a more capable IT team develops something, a web-app in this case, to keep their customers from having to put the resources into developing it. But this implies they may not have the resources to build client side code as well.

Then there are some clients who will have resources, and may want to integrate your web-app into something more comprehensive. This is where SOAP or REST can make this easier for them.

Answer 3

In addition to the excellent points that Chris makes, adopting an open-standards-based API means that even though you can create libraries to help clients that are using a particular platform (.NET, Java, etc.), you are still open to people who intend to use your API from other platforms.

Also, just because you're willing to create a client library now doesn't mean you will want to commit to maintaining it for years to come. Amazon put together some client libraries for their API, but by the time I tried using them they were hopelessly out of date and Amazon appeared to have no interest in fixing them. That's unfortunately the way business works. Having an open standard allows people to keep using the service even if your company fails to put resources into maintaining the client libraries.

Answer 4

It's a matter of opinion... I think that SOAP and REST are so standard that there's little point in providing client libraries. Generating client stubs from the WSDL should be trivial and allows full flexibility, so why shouldn't the customers do it themselves?

Unless, of course, the clients are not trivial - if you're doing something tricky or non-standard, then it would make sense for you to provide the client libraries for your service.

I think that whether you supply clients or not, the most important thing is to publish comprehensive documentation of your service.