是否为REST API使用单独的控制器？

Question

we are planning a REST api for our application and are trying to make a decision on if we should implement separate controllers for the REST functionality or not.

We could use the withFormat{} in our current controllers but separating the REST functionality in different controllers feels somewhat cleaner..

In that way we can build our API seperate from the current controllers and we could even take the REST controllers into another application etc.

Any thoughts on this subject? Any real world experience in what the best practice would be?

Answer 1

We recently faced the same decision and we decided to go for separate controllers for the REST API.

Advantages of separate controllers include cleaner/clearer controller actions and the possibility to support different versions of the REST API later on.

We also would like to keep the option to host the REST API on separate server instances open. These servers would use exactly the same .war, but with different configuration settings for the feature toggles .

A disadvantage of separate controllers might be the DRYness of the controller code. Although this should be limited, since IMHO you should keep the controllers as thin as possible and extract shared logic to Grails services or helper classes.

Answer 2

I will work with grails soon, but so far i have little experience with it. But in web apps i worked, we always left webservices separated from the controller code. We also separated REST from SOAP. Common methods for them would be in service layer. It, indeed, felt cleaner. We didn't had to insert a lot of if s in the methods

Answer 3

I would, for a given resource, use one controller that interfaces with a service layer based on context (the media type received or requested -- SOAP, JSON, XML, etc.) This way, you have a truly uniform resource identifier that can accept and return various media types and the controller won't need to know anything but what method the user wants to perform on what resource and what media type is involved.

For instance, maybe the service layer returns objects that have methods such as 'toXml', 'toSoap', or 'toJson'. Then you can just ask the service layer to do whatever and use a switch statement on the requested media type to either return the requested information, or by default throw a 406 Not Acceptable status code. For unsafe or idempotent transactions, the object may have constructor or factory methods for a given media type and then you just ask the service layer to do whatever with that object.