This question comes up a lot. This post talks about just one interesting way to approach it. When I first kicked off the conversation in a recent RESTful API Design webinar, I asked developers to chime in with ideas about how best to design for counts, and the conversation over on our API Craft Google group is underway. Check it out!
In the most post in this series about Pragmatic REST API design, I talked about handling responses that don't involve resources. This time, a somewhat related topic - search.
In a related post in this series about Pragmatic REST API design, I talked about partial responses and pagination. Check out the full series. This time: What's an API response that doesn't involve resources?
In a recent post in this series about Pragmatic REST API design, I talked about formats - supporting multiple formats and working with JSON as the default. This time, let's talk about what happens when a response comes back.
In the most recent post in this series about Pragmatic REST API design, I talked about pagination and partial response. This time we'll talk about formats? Should you support only one format or multiple formats?
This time - pagination and partial response - how do you give developers exactly the information they need?
Take for example the Twitter API - a request for a tweet. You'll get much more than a typical twitter app often needs - including the name of person, the text of the tweet, a timestamp, how often the message was retweeted, and a lot of metadata.
Let's look at how several...
In a recent tips for versioning post and on the RESTful API Design webinar, I described some best practices for versioning your APIs - move the v as far left in the URL as possible; place it at the highest scope (e.g. /v1/resources); and use a simple ordinal number, no dot notation.
I wanted to follow up with a little more on versioning, inspired by some great discussion on API craft (keep it coming!).
As I mentioned on the video, there is a strong school of thought about putting format and version in the header.
I think that...