Mixing REST and RPC logic in a Web API 2 project

Question

With Web API 2 and the recent addition, Attribute Routing gave me the idea of ​​creating a central API application for our corporate needs.

But my problem is that a clean REST approach somewhat limits our data exchange needs in the enterprise.

So, after reading THIS, I decided to follow the mixing method:

Some controllers have pure REST and some have RPC style.

Good idea from the article on routing (slightly changed it for RpcApi to add {id} placeholder):

routes.MapHttpRoute( name: "RestApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); routes.MapHttpRoute( name: "RpcApi", routeTemplate: "services/{controller}/{action}/{id}", defaults: new { id = RouteParameter.Optional } ); 

What I need to solve and you need your advice:

The separation between REST and RPC style / Categorization of domain operations :

Would it be a good decision to create 2 areas in my web API? One for RPC and one for REST?

But then how will I classify the work of my domain at the same level? (ERP, CRM, payroll). Initially, I thought that these would be relevant areas.

Another idea is to create a physical separation for the controllers in separate folders under the controller folder, although this would mean that there are unique names for the controllers, since the subfolders are not related to the infrastructure.

Additional Information:

Interesting view of ASP.NET MVC / Web API project organization

Any ideas?

Answer 1

I would not put all the services within the same solution and project, I would actually create separate projects and solutions for each service responsible for the "domain operation", as well as a REST project and one for RPC in this solution. The main reason for this is maintenance costs.

This is why I suggest having a separate solution that is responsible for each domain operation:

• Smaller deployment
• Minimize the dependencies of only those that you need for this project / solution
• More suitable for CI / CD, as you have less mergers and deployments and faster execution of suite testing against these solutions.
• Faster build time

Personally, I do not consider it necessary to use the REST infrastructure for RPC services in projects or has one huge solution that manages all the services. service level is an abstraction. Ultimately, it is the boundary that business objects must call to perform heavy lifting.

In addition, since it is necessary to create separate services in IIS on each server, this is an obstacle; if you do this manually, you must study the script for this operation to automate IIS creating a website and applications.

If you render your domain correctly, several service projects should be able to reuse the same business objects if necessary. You can even do it even further and set up an internal object repository, such as NuGet, to manage any common dependencies.