Organizing Master-Detail Controllers ASP.Net Web API

Question

I am trying to determine the best way to implement the retrieval of detail records based upon the master's ID.

Obviously you would set up API controllers for both master and detail.

Solutions I've considered:

• Have API consumers use OData to get all details filtered by a master ID. While I don't have an issue with this solution, I kinda feel bad putting that onto the API consumer and feel it is something that should be handled internally by the API
• Go against the convention of just having the Get/Put/Post/Delete methods and create an action of "GetMastersDetails" on the detail controller and make it accessible via routing. While this would certainly work, I feel this gets away from the whole point of Web API (to an extent).
• Create a 3rd controller named "MastersDetailsController" which would have a Get based upon a master ID with different possible return types:
  • Which would return a list of detail IDs which would then be used to call a Get on the details controller to get those actual details
  • Which would return a list of actual detail objects. What I don't like about that is having a controller returning a different type than what it is based upon.

Answer 1

I'd go with either #1 or #2.

For #1, OData support enables not only the scenario you describe but offers a lot of additional functionality which might be desired in the future.

For #2, I don't think it gets away from the point of Web API's. Maybe a bit from a true RESTful service, but it's easy to implement and easy to understand.

Answer 2

Option 2 will be fine. Option 1 opens up a lot more risk depending on your scenario, and what you want to allow the user to get at.

It's not really "against convention" to add custom methods to an ApiController. You can do that however you like. It would only be "against convention" if you did so and used the wrong HTTP methods (ie a GET when you're deleting something in your custom method).