Defining sub-resources for your RESTful API

Defining your sub-resources: map your endpoint URLs

Some of your resources can be considered as sub-resources. For example, consider a support ticket with multiple comments. Let’s say you want to retrieve all of the comments for ticket #123.

  • GET /tickets/123/comments: get all comments for ticket #123
  • GET /tickets/123/comments/2: get comment #2 for ticket #123
  • POST /tickets/123/comments: create a new comment for ticket #123
  • PUT /tickets/123/comments/2: update comment #2 for ticket #123
  • DELETE /tickets/123/comments/2: delete comment #2 for ticket #123

Implementing your resource relations: relations in the NoSQL world

Even though this series of articles is not about RESTful API implementation, but about RESTful API design, I still wanted to include this paragraph, as I believe it is important and might save you from a complete rewrite of your API after you found out the hard way that it will not scale well.

{
id: "123456",
subject: "Message 1",
message: "This is my first message",
author: {
id: "123",
name: "Guillaume Viguier"
}
}

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Guillaume Viguier-Just

Guillaume Viguier-Just

Développeur web et passionné de finances personnelles