Should I separate RESTful API controllers from "regular" controllers?

This seems like an elementary question, but after a lot of searching around I can't seem to find a straightforward explanation:

If I'm building a web application that is going to开发者_如何学运维 be accessed largely through a web browser, but that will also support some API requests in a RESTful way, should there be a large degree of separation between the two?

On one hand, it seems a large amount of the functionality is the same, with identical data presented in different views (HTML vs. XML/JSON). But on the other hand, there are certain things I need to present to the browser that doesn't quite fit a RESTful approach: how to get an empty form to create a new instance of a resource and how to get a pre-populated form to edit an existing resource.

Should these two different methods of accessing the system by funneled through different controllers? Different methods in the same controller? The exact same methods with a switch for view type?

Your core controllers don't have to change, but that doesn't mean you can't have some extra ones solely to support you UI. For example, both of the Form examples you have can be unique to the Web API. Your entry URIs can certainly have links to those pages for both the machine and user interface, just don't expect the machine users to actually use them.

Also, if your machine clients are simply XML/JSON, then those representations don't need those links at all to the forms, since they'll not use them, and they don't "work" in JSON/XML anyway. You can manage that through Content negotiation.