Designing a Beautiful REST+JSON API
Why Stack Overflow recommends it
Stack Overflow users link it when answering REST design questions about HTTP verb mapping, partial updates, resource linking, pagination and API authentication.
Recommended by 5 people across 4 different months, 2013 to 2015.
What it is
A conference talk from InfoQ in which Les Hazlewood, then CTO of Stormpath and chair of the Apache Shiro project, walks through lessons from building JSON-based REST APIs in Java. It covers linking, pagination, mapping HTTP methods to CRUD, partial updates, versioning, error responses, caching and security.
What people said
Strong rec Zed · 2013-02 · Stack Overflow · on “RESTful API, where to place the Authorization key”
Take a look at Designing a Beautiful REST+JSON API [this video] talk by Les Hazlewood ( here are the slides [LINK] ). Les Hazlewood as a Stormpath CTO and Apache Shiro PMC Chair knows a thing or two about security. Very nice talk.
Recommends pleshy · 2013-02 · Stack Overflow · on “Which HTTP methods match up to which CRUD methods?”
There's a great youtube video talk by stormpath with actually explains this, the URL should skip to the correct part of the video: stormpath youtube video [this video] Also it's worth watch it's over an hour of talking but very intersting if your thinking of investing time in building a REST api.
Recommends PositiveGuy · 2013-10 · Stack Overflow · on “Use Hypermedia instead after first Level in rest URI?”
I've figured out my own solution. That is to use Hypermedia as a means to manage Resource Linking (relationships) rather than deal with and have your users deal with longer complicated URIs. Anyway, watch this and you will understand, he puts it perfectly. [this video]
Recommends PositiveGuy · 2013-10 · Stack Overflow · on “Use Hypermedia instead after first Level in rest URI?”
then you don't understand hypermedia (Resource linking). watch this, it will allow you to trim and not have so many complicated URls for your REST API. [this video]
Recommends inf3rno · 2014-05 · Stack Overflow · on “Writing a REST API for Complex Nested Data”
Btw. describing n:m relations this way wasn't my own idea, maybe watching this can help: [this video] by designing your api.
Recommends MStodd · 2015-07 · Stack Overflow · on “Best practice for partial updates in a RESTful service”
It doesn't matter. In terms of REST, you can't do a GET, because it's not cacheable, but it doesn't matter if you use POST or PATCH or PUT or whatever, and it doesn't matter what the URL looks like. If you're doing REST, what matters is that when you get a representation of your resource from the server, that representation is able give the client state transition options. If your GET response had state transitions, the client just needs to know how to read them, and the server can change them if needed. Here an update is done using POST, but if it was changed to PATCH, or if the URL changes, the client still knows how to make an update: { "customer" : { }, "operations": [ "update" : { "meth
Cites Snekse · 2013-06 · Stack Overflow · on “How to apply delta changes of JSON into original object in Jackson / Play 2.0?”
Side note: The HTTP method should be a `POST` in this case. [this video] Using `PUT` for an update should send the entire object, not a delta.
Cites inf3rno · 2014-09 · Stack Overflow · on “RESTful API - URI Structure Advice”
By pagination you can use range headers as an alternative. So `/users` `Content-Range: 26-50/1234`. This should return almost the same as `/users?offset=25&count=25`, except the next and previous links ofc. Now do the different pages belong to different resources? I don't think so. By range headers they belong to the same resource... Both range headers and query pagination params are REST best practices. For example by pagination: [this video] , but you can find a lot of articles about how to paginate by REST.