Observations on API and Mashup Management API and Mashup Blog
Tags
affliate marketing analytics announcement API Apigee API management API Proxy API Tips case study cloud API collaborative consumer debugging Design developers development example facebook features feed fixes flickr howto iPhone ipnone latency login mashup monetization monitoring notfications performance proxy response time setup sharing twitter UI vision web APIArchives
API technology (1)
Apigee how-to (3)
Announcements (4)
HowTo (1)
Screencast (1)
Thoughts (2)
Subscribe to This Blog
API Tip of the Day: Self documenting code is an ideal
Read the API carefully as you write it. Does it read clearly? Can new users make sense of it quickly? Twitter’s “statuses/mentions” is a good example – you’ll HTTP GET the mentions of the user account you’re calling from. Readable APIs mean easy-to-adopt APIs.
API Tip of the Day: Involve the users early
Your API exists for the use of developers. You’ll probably get it wrong the first time. With a tight feedback loop between developers who use the API and those who build the API you can get it right quickly. In turn these early users will help promote the API and help new users get productive.
API Tip of the Day: Don’t put verbs in your API
The accepted verbs for REST APIs are contained in the HTTP Request: GET and POST. Realistically PUT and DELETE are not always available due to IT standards for security on web servers. Try to design your interface from the point of view of using just GET and POST as your verbs.
API Tip of the Day: Learn from the masters
Joe Gregorio’s original column from 2004 is just as relevant today as it was then. It covers the four fundamental design questions that authors of a REST API must ask and answer. Find it here: http://www.xml.com/pub/a/2004/12/01/restful-web.html
API Tip of the Day: REST Means Exposing a Resource
Ideally an API exposes a resource that can be manipulated. While there may be multiple ways to organize those resources into categories and lists, at the end of the URL you are exposing a resource. This is a core principle of the REST pattern. Look at the problem from the resource’s perspective, not the perspective of the method.