So I’ve recd. a requirement to create an API to access our application. Not all controller actions are covered by the API (maybe 50%).
I figure I can either use the same project, check the http headers for each request and respond with either xml, JSON or html as required (much like rails).
OR
Create a new ASP.NET MVC application, deploy @ api.myapp.com and use it exclusively for API access.
I assume I could write a base controller for the first option to handle 99% of the work. The issue with the first option is we don’t need (or want) API functionality for at least 1/2 of controller actions (and prob. never will).
In the second option I have a duplicate of some controllers, but the good news is most/all? my controller actions are only a couple lines of code. Typically:
Whatever whatever = new Whatever(....); repository.Save(whatever);
Anyway, what do the stack overflowers think?
It seems that you want to create something like REST service. Please have a look at this post of Phil Haack.
Yes, I’m sure you can put it in the same project. But it will be better to separate them in some way (using areas from MvcContrib or move controllers of api and web application to separate assemblies like this done in SharpArchitecture. If your controllers duplicate a lot of code you may create generic controller like:
Hope this helps.