咨询AspnetBoilerplate创建RESTful API且兼容ServiceProxies的替代方案

Great question! I’ve tackled this exact scenario with ABP before, so let me walk you through practical, low-effort alternatives that avoid a full rewrite of your existing WebAPI layer while keeping your ServiceProxies working smoothly:

1. Adjust Routes on Existing ABP App Services (Simplest Approach) #

ABP’s dynamic Web API system generates endpoints based on your app service names and methods by default (like /api/services/app/User/GetUser), but you can easily override this with standard ASP.NET routing attributes to make them RESTful—without changing your service logic.

Just add [Route] and HTTP verb attributes (like [HttpGet], [HttpPost]) to your app service methods, alongside ABP’s built-in attributes (like [AbpAuthorize]). Here’s an example:

[AbpAuthorize]
public class UserAppService : AsyncCrudAppService<User, UserDto>
{
    // RESTful endpoint: GET /api/users/{id}
    [HttpGet]
    [Route("api/users/{id}")]
    public override async Task<UserDto> GetAsync(int id)
    {
        return await base.GetAsync(id);
    }

    // RESTful endpoint: POST /api/users
    [HttpPost]
    [Route("api/users")]
    public override async Task<UserDto> CreateAsync(UserDto input)
    {
        return await base.CreateAsync(input);
    }
}

This works because ABP’s dynamic API generator respects ASP.NET routing attributes, and your existing ServiceProxies will still function normally—they’re just pointing to the new RESTful routes instead of the default service-based ones.

2. Add a RESTful Wrapper Controller (No Changes to Existing Services) #

If you want to keep your original app service routes intact (for backward compatibility) while adding separate RESTful endpoints, create a standard ASP.NET Web API controller that injects your existing app service. This acts as a "wrapper" that translates REST requests into calls to your existing service methods.

Example controller:

[Route("api/users")]
public class UsersRestController : AbpApiController
{
    private readonly IUserAppService _userAppService;

    public UsersRestController(IUserAppService userAppService)
    {
        _userAppService = userAppService;
    }

    [HttpGet("{id}")]
    public async Task<UserDto> GetUser(int id)
    {
        return await _userAppService.GetAsync(id);
    }

    [HttpPost]
    public async Task<UserDto> CreateUser(UserDto input)
    {
        return await _userAppService.CreateAsync(input);
    }

    [HttpPut("{id}")]
    public async Task<UserDto> UpdateUser(int id, UserDto input)
    {
        input.Id = id;
        return await _userAppService.UpdateAsync(input);
    }
}

Since this controller inherits from AbpApiController, it automatically gets ABP’s features like authorization, exception handling, and localization. Your original ServiceProxies keep working with the old routes, and you get a clean RESTful API for new clients.

3. Customize Service Proxy Generation (Advanced) #

If you want your front-end ServiceProxies to directly use the RESTful endpoints (instead of the default method-based proxies), you can tweak ABP’s proxy generation logic.

For Angular, for example, you can modify the service-proxy.module.ts to create custom proxies that target your REST routes while keeping the rest of the proxies generated normally. This is useful if you want a unified front-end API layer that mixes both ABP’s service proxies and REST calls.

Keep in mind this is more advanced—stick with the first two methods unless you have specific custom proxy needs.

All these approaches let you add RESTful features without rewriting your existing WebAPI layer, and they maintain compatibility with ABP’s ServiceProxies. The first method is the most straightforward, while the second gives you full separation between old and new endpoints.

内容的提问来源于stack exchange，提问作者user2058413