So far in the API design series, I've looked at best practices for designing pragmatic RESTful APIs. This time, I'll talk about complementing APIs with code libraries and SDKs. What to do when building a UI requires a lot of domain knowledge?
In this post in the series, let's think about how app developers use that API you're designing and dealing with chatty APIs. Imagine how developers will use your API. When designing your API and resources, try to imagine how developers will use it to say construct a user interface, an iPhone app, or many other apps.
We've covered singular vs. plural nouns to label your resources, tips for search, handling errors, and more. Now lets take a look at what some API requests and responses look like for our dogs API.
I've talked about versioning as one of the most important considerations when designing your pragmatic RESTful API. So it deserves another mention, keeping in mind basic versioning recommendations, such as:
- How many versions should you maintain?
- For how long should you maintain a version?
This time, in this series about pragmatic RESTful API Design, I'll discuss authentication. There are many schools of thought - my colleagues at Apigee and I don't always agree on how to handle authentication - but overall here's my take. Let's look at how PayPal, Facebook, and Twitter handles things differently.
In the last post in this series, I talked about the top level domain (the stuff on the other side of the URL) and in this RESTful API design series so far, I've dealt with baseline, standard behaviors. This time I'll explore some of the exceptions that can happen - when clients of Web APIs can't handle all the things we've discussed. For example, sometimes clients intercept HTTP error codes, or support limited HTTP methods. What are ways to handle these situations and work within the limitations of a specific client?
In the series so far, we've talked about everything that comes after the top level domain. This time, let's explore stuff on the other side of the URL. We'll look at how Facebook, Foursquare, and Twitter handle this.