Reputation: 49047
I am creating a web service following the REST style so I am using JAX-RS. However, the question is in the more general form so the technology shouldn't matter.
Let say you have three resources in your system.
Quiz, Question and QuestionFeedback. Now let say you create a path for the Quiz resource: /quiz
One quiz object has a list of questions, and the each question has a list of feedbacks.
I also have a path for questions: /questions
and you can POST
feedback on the sub-resource (is that the correct term?) on the question so let say: /question/1/feedback
.
However should this path be available through the quiz too? Are there any rules on this, or is this up to the developer (of course it is.., but is it usual)?
Example: /quiz/questions/1/feedback
. What I am trying to ask is where the boundries goes. Should you make the same operations available in nested path, the same way as you do when they are "top level" path?
Upvotes: 2
Views: 723
Reputation: 80593
We have been utilizing the composition vs aggregation rule in our web services implementation. The basic premise being that resources that are composited have their life cycles fully managed by their parent resource. Whereas those that are aggregated are only managed from an association point of view
So given a parent resource, we (typically) map the HTTP verbs to management operations on the sub resource like so:
Composition Aggregation POST create associate GET read read PUT update reassociate DELETE delete disassociate
For composite GET's we define enough end points to fully query the sub resource. For aggregated GET's we only return enough information to define the actual endpoint to do a full query on.
Som if we were coding up a Quiz API, we would have
But not:
Upvotes: 4