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...
In the last post in this series about Pragmatic REST API design, I talked about designing error conditions in your APIs. This time - versioning - one of the most important considerations when designing your pragmatic API.
In the previous posts in this series about Pragmatic REST API design, I talked about simplyfing associations, using the HTTP ? to hide complexities and optional parameters, choosing plural nouns and concrete names, and more. What about errors in the context of RESTful API best practices? Many software developers, including myself, don't always like to think about exceptions and error handling but it is a very important piece of the puzzle for any software developer, and especially for API designers.
In the previous post in this series about Pragmatic REST API design, I talked about choosing plural versus singular nouns and concrete names over abstract. See RESTful API Design: plural nouns and concrete names. This time we'll explore API design considerations when handling associations between resources and parameters like states and attributes.