0

So here's my dilemma. I've sort of read up on how to design 2-way relationship APIs but I haven't found an answer to my question yet.

Say I have 2 entities, one is called 'Event' and the other is called 'Person'. Now, if I want to add a person to an event, I could either choose something like POST events/{event-id}/persons sending the person-id in the body OR I could have something like POST persons/{person-id}/event sending the event-id in the body of the request.

Which of these 2 would be most appropriate? I'm using a NoSQL database and I'm maintaining the 2 way relationship using data redundancy, e.i I'm storing all the event IDs for a person as well as the person Ids for an event.

  • 1
    What do the requirements say? Are there 2 differentiated use cases where a person can be added to an event and vice-versa? Anyways, are not both endpoints going to end up executing the same business logic? – Laiv May 29 '17 at 9:25
  • Yeah, both of these endpoints are possibly going to end up implementing the same business logic. However as an APi desinginer ,I ought to make sure that the client side application developers make sense of it – bholagabbar May 29 '17 at 9:33
  • 1
    Say we were speaking about the domain data model and we were implementing the business. How would you solve the 2-ways relationship? From my little perspective of the situation, Events and Person management could be different bounded contexts (I don't know exactly if it makes sense in your case). So I would consider having two different endpoints. For certain clients could make sense just add persons to events and for other clients could make sense just the opposite. Summarising, There's nothing wrong with having two endpoints as soon as everything is well documented. – Laiv May 29 '17 at 9:40
2

This is how I see it:

You are adding person to the event:

events/{event-id}/persons

You are adding event to the person:

persons/{person-id}/event

So, the question is, which one are you trying to do?

If the requirement is to support both then from my personal reasoning both endpoints are alright. Otherwsie pick the endpoint that matches the requirement.

  • Endpoint 1 and 2 both achieve the same thing? That was the issue. Internally, both are going to be linked to one another – bholagabbar May 29 '17 at 17:44
  • 2
    How internals resolves the business logic is a question that has nothing to do with REST. Make both endpoints call the very same business process or implementat 2 different business process. That's up to your. – Laiv May 29 '17 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.