14

I am developing a generic REST API for my projects and I'm wondering what to do when I have a table/resource with 2 or more primary keys.

For example, lets suppose I have a table named "question" with two primary keys (date and type) and I need to create the resource REST URI. What is the best way to do it following the standard schema api/{resource}/{id}?

Maybe something like: api/question/{:date},{:type}? What is the best way to do it?

Thank you.

Dherik
  • 17,757
  • 11
  • 115
  • 164
angro
  • 160
  • 1
  • 1
  • 7

4 Answers4

4

I think that what you call multiple primary keys is a composite key. Right?

You have some options.

Use api/questions/dates/:date/types/:type

Maybe, the best alternative for you is:

api/questions/dates/{:date}/types/{:type}

This is more natural to read as a http resource for your case, even if don't make sense have a api/question/dates/{:date} in your application.

Use api/questions/:date/:type/

Another alternative is:

api/questions/:date/:type/

Use query parameter

If it's no a problem for you, instead of return a single object question you can return an array of questions as response using a filter query, like:

api/questions?date=2022-10-27&type=XYZ

Both are not mandatory, but if the user send both, the return will be always an array with a single element. Also this bring some flexibility to your API, because the user can inform just one of them and have some results. You need to check if this behavior it's valid for your case.

Dherik
  • 17,757
  • 11
  • 115
  • 164
  • 1
    Great approach. – deFreitas Feb 18 '18 at 20:13
  • What about if your entity has as composite id another entity id. Express the whole hierarchy? We are putting trivia just to follow the hierarchy suggestion as we actually just need topicId and questionId to retrieve a question trivia/topic/topicId/question/questionId – user33276346 Jan 05 '21 at 02:07
  • Why the negative? Seems to me a valid approach. – Dherik Oct 27 '22 at 15:52
3

You're on the right path, I think you definitely should include both the date and the type in the resource url if that's the only way you can uniquely identify it

api/question/{date}_{type}
Alexandru Marculescu
  • 5,569
  • 6
  • 34
  • 50
2

This is a good example of when to use a slug. This answer to What is a slug provides a good idea of how you can use your composite primary key in your api design.

with that, you have a few options at your disposal. Which is the best would be a matter of opinion and what suits your needs.

  • api/question/{:date}/{:type} or api/question/{:key1}/{:key2}/.../{:keyn}

The same pattern could also be applied to the following.

  • api/question/{:date}_{:type}

  • api/question/{:date}-{:type}

Community
  • 1
  • 1
Nkosi
  • 235,767
  • 35
  • 427
  • 472
1

I do not find it a good idea of having two primary keys for a resource. REST heavily depends on resources and it's representations.

If you are struck into situation where you are ending up with two identifiers for a resource - then redesign your application (may be by creating another key in backend after mapping it to other identifiers) and add these multiple keys as attributes in resource.

Idea is - "keep it simple" if you want to create truly world class REST APIs.

Bonus: You don't need to teach few extra things to clients/developers about something fancy you did with your APIs.

Lokesh Gupta
  • 463
  • 5
  • 8