Providing an API is only half the rent

It’s nearly considered good manners to provide an API if you are running some serious e-business. Exposing some of your business artifacts makes you integrable, mashable simply buzzable. But how about your business logic your artifacts are bound to? If you only want to give a simple listing API to your customers so that they are able to create their own views on your exposed data you’ll ‘only’ have to think about security and traceability of your desired interface. But as soon as your first customer wants to modify your data using the API you should slink into your cave and plot your plans.

By now Spreadshirt provides a simple listing API that permits you access to some artifacts of your own shop and enables you to create your own front end and get in touch with the Spreadshirt basket. As this is an API for the shop you are not able to create new articles or modify existing ones. If you want to create or buy a neat shirt you have to visit our site and use the T-Shirt Designer.
In the recent past more and more shop partners come up with very sophisticated ideas on how they want to use Spreadshirts logic to get their shirts printed. In some cases they are running some breed of custom shirt designer tool which exactly fits to the needs of their business and they come over to us saying: “Hey! We have this cool tool! We simply send you the text to be printed along with color and size of the shirt and everything should be fine.” At this point my face fades to white, the complex data model for describing a shirt plops into my mind and i find myself saying: “Well, we can do this - but …”

During the preparations for our cooperation with CNN.com i was caught exactly in the situation described above. CNN told their agency to develop an application which shows CNN headlines on shirts and the user should be able to choose the text color and the color, fabric, size of the shirt. When the agency finished the UI part we where asked how they should submit their data. Some conference calls later it turned out that we where not able to explain our data model to them and every further shot only results in more confusion on both sides. So we decided to provide a sophisticated API which comes with the minimum set of required data. The problem seems to be solved but the next was right around the corner: They simply where not able to use the API because they had no idea how to interact with a SOAP web service in Flash. Finaly we boiled it down and offered a solution which satisfied both sides.

Why i’m telling this? Because, the CNN cooperation has learned me some essentials on API design:

  1. Your API can offer a thousand possibilities. If it is to complex you will frighten off our potential users.
  2. Provide a library for your API which cares about the communication with your interface. This will dramatically lower the entry level for your fellows and raises the acceptance.

There are a lot of reasons for bundling a library to your API but they are not scope of this post. In one of my next posts i’ll try to explain why i’m so crazy about that library support thingy .

Best,
Frank

This entry was posted on Thursday, May 1st, 2008 at 1:20 pm and is filed under API. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply