91–100 of 101 posts
Restful service design - https://drive.google.com/open?id=0B8qU9uFznmLsUEZ3TEFMbDZQcU...
Notes on RESTful APIs - http://wooptoo.com/blog/notes-on-restful-apis/ - written by yours truly some years ago
REST API Design Rulebook, Designing Consistent RESTful Web Service Interfaces, by Mark Masse http://shop.oreilly.com/product/0636920021575.do
When doing my last bigger API i read every recommendation. Still learned a lot. Everyone has different recommendations - dont get discouraged by this. Make sure also to look into newer standards like JsonAPI if they are suitable - last time i tried to use it the tooling around it was still not strong enough and i decided to go w/ simpler custom api. Assuming it has to be a restful api (vs graphql) and assuming you wa…
Until you hear from an iOS developer that it is a huge pain trying to figure out if the user has left a comment on an item or not and including this little flag would save tons of time.
You'll notice in this thread that (at 9 comments in) there are no repeated recommendations. If the question was "What are some good reads for learning about algorithms?" you'd probably see the same handful of books being praised by everyone. Don't be overwhelmed by this though -- API design isn't an exact science. It's also very opinionated. Personally, I would just start reading actual API documentation (GitHub is a…
The Little Manual of API Design (Trolltech/Nokia): http://people.mpi-inf.mpg.de/~jblanche/api-design.pdf How to Design a Good API and Why it Matters (Josh Bloch): http://static.googleusercontent.com/media/research.google.co... https://www.youtube.com/watch?v=aAb7hSCtvGw
He keeps writing like he's an expert and I am still waiting for evidence to back that up,
Earlier quoted context omitted.
Never nest data (not `post: { author: { … } }` but reference only `post: {author_id: …}`) I'm creating a huge API on my dayjob and we have nested A LOT. So many levels of nesting, the responses have become too big. Yet, the clients refuse to call additional endpoints and always insist on this. And it _does_ make sense for them to make 1 call and retrieve all information they need. How does everyone handle this on RES…
If you must, serve up the authors as an array that is a sibling of the posts array. So if you have 100 posts written by only 3 authors, you have: { posts: [ /* 100 records */ ], authors: [ /* 3 records */ ] } Each post references the author by ID only and all required data is sent in one API call.
C Interfaces and Implementations: Techniques for Creating Reusable Software By David R. Hanson
You'll notice in this thread that (at 9 comments in) there are no repeated recommendations. If the question was "What are some good reads for learning about algorithms?" you'd probably see the same handful of books being praised by everyone. Don't be overwhelmed by this though -- API design isn't an exact science. It's also very opinionated. Personally, I would just start reading actual API documentation (GitHub is a…
lets look at how not to design an http API
When doing my last bigger API i read every recommendation. Still learned a lot. Everyone has different recommendations - dont get discouraged by this. Make sure also to look into newer standards like JsonAPI if they are suitable - last time i tried to use it the tooling around it was still not strong enough and i decided to go w/ simpler custom api. Assuming it has to be a restful api (vs graphql) and assuming you wa…
- Never embed personalized information (eg not `{ post: { user_has_commented: true } }` Until you hear from an iOS developer that it is a huge pain trying to figure out if the user has left a comment on an item or not and including this little flag would save tons of time.
you can just add it as separate key (similar how you embed eg user objects)
``` posts: {…} interactions: { commented_on_posts: [1212,12,1212,121] } ```
btw most people over estimate this problem the _total_ amount of user interactions is usually very small
in almost all cases you could download it once at boot for the user.
Earlier quoted context omitted.
Wouldn't most people disagree with: "not `/posts/343/comments` but `/comments?post_id=232`"?
This is one issue I struggled with in my last API design. I generally like the /comments?post_id=232 format but in many cases it's not intuitive. Especially when the sub-resource (i.e. comments) is only ever referenced in with a parent resource (i.e. posts). This is a bit of a contrived example but with a structure like /comments?post_id=232, a developer might mistakenly assume comments are independent resources and…
you end up w/ a lot of filters very quickly and related post id will be just one of them
also linking it to another resource usually involved expecting defaults (default ordering, default display, pagination etc)
if you stay "flat" this tends to be less of an issue when usecases become more complex