11436 SSO

Posts

Technology
by Brian Mulloy Dec 28, 2011
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. Check out the full series. This time, let's talk about what... Read more
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.
606
Technology
by Brian Mulloy Dec 28, 2011
In the most recent post in this series about Pragmatic REST API design, I talked about pagination and partial response. Check out the full series. This time: What about formats? Should you support only one format or... Read more
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?
606
Technology
by Brian Mulloy Dec 23, 2011
In a recent post in this series about Pragmatic REST API design, I talked about tips for versioning your APIs. Check out the full series. This time - pagination and partial response - how do you give developers exactly... Read more
In a recent post in this series about Pragmatic REST API design, I talked about tips for versioning your APIs. Check out the full series. This time - pagination and partial response - how do you give developers exactly the information they need? Partial response 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 leading APIs handle giving developers just what they need in responses, including Google who pioneered the idea of partial response. LinkedIn /people:(id,first-name,last-name,industry)
606
Technology
by Brian Mulloy Dec 06, 2011
In the last post in this series about Pragmatic REST API design, I talked about designing error conditions in your APIs. Check out the full series. This time - versioning - one of the most important considerations when... Read more
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.
606
Technology
by Brian Mulloy Dec 05, 2011
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... Read more
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.
606
Technology
by Brian Mulloy Nov 30, 2011
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... Read more
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.
606
Technology
by Brian Mulloy Nov 29, 2011
In the first post in this series, Are you a Pragmatist or a RESTafarian?, I proposed that "pragmatic REST" is a design issue. In the second post, RESTful API Design: nouns are good, verbs are bad, I outlined... Read more
In the first post in this series, Are you a Pragmatist or a RESTafarian?, I proposed that "pragmatic REST" is a design issue. In the second post, RESTful API Design: nouns are good, verbs are bad, I outlined some of  the API design practices that work well: Nouns in URLs are good. Verbs are bad. Try to limit your API to 2 base URLs per resource. This time, we'll explore how to pick the nouns for your URLs. Plural nouns are better than singular Should you choose singular or plural nouns? You'll see popular APIs use both. Let's look at a few examples  - key resources for these businesses are expressed as either singular or plural:Foursquare /checkinsGroupOn /dealsZappos /Product
606

Microservices Done Right

Next Steps

 
 

Resources Gallery

News