RESTful API Design - Second Edition
Why Stack Overflow recommends it
Stack Overflow users link it when answering REST questions about URL structure, resource design, response formatting and endpoint layout, since it gives practical conventions rather than theory.
Recommended by 7 people across 7 different months, 2012 to 2017.
What it is
A 55-minute webinar by Brian Mulloy of Apigee, the second edition of their API design talk, covering pragmatic REST API design, common anti-patterns, and handling data formats and errors. It pairs with Apigee's free 'Web API Design: Crafting Interfaces that Developers Love' e-book and slide deck.
What people said
Strong rec Bruno · 2012-11 · Stack Overflow · on “What are good examples of REST API client libraries in JavaScript”
I watched a really good video on good API Design. Definitely worth the watch. RESTful API Design - Second Edition [this video] You can also get a free book Web API Design - Crafting Interfaces that Developers Love in addition to the above video by going to [LINK] Regarding wrappers it may be worth thinking about the following: Make your wrapper consistent. Adopt the standards, naming conventions, etc of the programming language or community you are working with to make the wrapper feel as natural as possible to those using it. To wrap or to abstract? That is the question. By Wrapping you mimic the REST API methods and structure as much as possible but simply make some of the hard things easier. O
Recommends MMM · 2012-10 · Stack Overflow · on “Standardizing the JSON response”
First, you should really take a look at the video RESTful API Design [this video] from the apigee guys. It contains a ton of good advice for RESTful APIs. Brian Mulloy gives also feedback on how responses should look like. Next, you should take a look at some libs in php for developing RESTful APIs. Some of these gives you a solid way of how to return responses. [LINK] [LINK] [LINK] or more [LINK] With this you should good to go to build well RESTful APIs.
Recommends miku · 2013-01 · Stack Overflow · on “How would REST handle post-processing / including relevant resources?”
Having a verb in a query parameter is not necessary un-RESTful. I would say that it is common (and more important) to have clean resources and verbs, but to include more involved functionality into query parameters, as you would do with ?includePostingUsers=true . Apigee published a nice pragmatic booklet on Crafting Restful APIs: Web API Design – Crafting Interfaces that Developers Love [LINK] (PDF), and a related video with real world observations: [this video]
Recommends Pevara · 2013-04 · Stack Overflow · on “Using GET and POST vs getter and setter methods (URLS)”
What you are refering to is a RESTful API. While not required (you could just use getters and setters) it is indeed considered good practice. This however does not meen you have to change the code of your data objects. I always use getters and setters for my business logic in the models layer. What you are talking to through the HTTP request are the controllers however, and they rarely use getters and setters (I suppose I do not need to explain the MVC design pattern to an experienced programmer). You should never directly access your models through HTTP (how about authentication and error handling and stuff...) If you have some spare time I would advise you to have a look at this screencast
Recommends Adam Plocher · 2014-10 · Stack Overflow · on “API URL Structure”
This was published just a couple weeks later (Nov 2011 instead of Sep 2011), but it's the "second edition" version of that same webinar. I have yet to watch either, so I can't say with experience yet [this video]
Recommends Francois Taljaard · 2015-02 · Stack Overflow · on “REST actions and URL API design considerations”
@SamStorie take a look at this, [this video] at 19:29 and 39:00 min . Also a slide share [LINK] (slide 48 and slide 74).
Recommends Ivan Semochkin · 2017-02 · Stack Overflow · on “REST where should end point go?”
When I started to create an API, I was thinking about the same question. Video from apigee [this video] . help me a lot. In a nutshell when you decide to build an API, you should decide which entity is independent and which is only related to someone. For example, if you have a specific endpoint for orders with create/update/delete operations, then it will be fine to use a second approach /order/?user=3 . In the other way, if orders have only one representation, depends on a user and they don't have any special interaction then you could first approach. There is also nice article about best practice [LINK]