I am designing an API and am having a couple of problems with certain parts of the resource modelling.
I have the notion of a
SurveyItem which as a collective form a
Survey Resource Endpoint: http://api.somewhere.com/survey Accessing Survey Items http://api.somewhere.com/survey/1/surveyitems
Pretty basic and i am not overly concerned with the above.
SurveyItems cannot exist outside the context of a survey hence the hierarchy.
Where i am struggling a little is the next level down. A
SurveyItem is not necessarily one thing (bear with me) as it is based on an interface which is implemented but you may have something like a "Simple Survey" that lets you take notes, a "Video Survey" will let you take a survey via video etc, so they are all the all part of the base implementation but could potentially have different sub resources.
Image and note survey type sample endpoints http://api.somewhere.com/survey/1/surveyitems/1/images http://api.somewhere.com/survey/1/surveyitems/1/notes Video Survey http://api.somewhere.com/survey/1/surveyitems/2/videos http://api.somewhere.com/survey/1/surveyitems/2/notes
As you can see above a
SurveyItem may have different sub endpoints depending on the type of SurveyItem it is. I was thinking of modelling it the way above but using a HATEOAS approach of responding with a collection URLs of the available sub endpoints for each individual survey type so they are discover-able by clients.
Is this a reasonable thing to do or are there better approaches to handling things like this?