RESTful (WebAPI) 服务中的非 CRUD 操作

本文关键字:CRUD 操作 服务 WebAPI RESTful | 更新日期: 2023-09-27 18:32:53

我正在通过将现有的WCF服务转换为WebAPI来学习WebAPI(以及一般的REST(。 在这个过程中,我对处理非 CRUD 操作的最佳方法感到困惑。 这是我的服务合同:

[ServiceContract]
public interface IProxyHelper
{
    [OperationContract]
    List<ProxyInfo> GetUsersCurrentUserCanActAsProxyFor(int positionId, int appId);
    [OperationContract]
    void DeleteProxy(int id);
    [OperationContract]
    List<ProxyInfo> GetProxyData(int appId);
    [OperationContract]
    bool CanPositionProxy(int positionId, int appId);
    [OperationContract]
    void AddProxy(
      string userRacf,
      string proxyAsRacf,
      int userPositionId,
      int proxyPositionId,
      string requestedByRacf,
      int appId);
    [OperationContract]
    int GetPositionIdByRacf(string racf);
    [OperationContract]
    string GetRacfByPositionId(int positionId);
}

一些方法,如DeleteProxy和AddProxy I可以很容易地转移到基于CRUD的方法。

问题出现在以下方面:

GetProxyData - 代理系统由多个应用程序使用,虽然我可以做 api/Proxy/1,但我觉得这是"作弊",因为这应该是为了获取 ProxyId 1,而不是应用程序 1 的代理。

GetUsersCurrentUserCanActAsProxyFor - 这对我来说在多个层面上令人困惑。 我应该如何处理多个参数? 而且它也没有完全落入 CRUD 方法。

这是否意味着我应该放弃 WebAPI 转换? 如果没有,我应该如何处理这些非标准方法?

RESTful (WebAPI) 服务中的非 CRUD 操作

我认为您将RESTful服务与CRUD混淆了。两者并不相同,尽管很明显,将 CRUD 转换为 REST 非常简单(资源和动词都有明确的映射(。

RESTful 架构的最大区别在于它是面向资源的。第二个是你利用传输(HTTPs(协议来对这些资源进行操作 - 在REST的情况下,是GET,POST,PUT和DELETE。

转到您的示例,似乎您最大的麻烦是决定用于支持此服务的 URI 方案。我可以建议,对于分层信息,这应该是直截了当的。例如,应用程序代理:

/application/<id>/proxies

并且当前用户可以充当以下用户的代理:

/user/<id>/proxy-users或取决于您的风格/user/<id>/proxy/users

或类似的东西。您考虑的是关系和基础资源。许多 URI 可以指向同一资源。

请注意,正如@dtb在他的评论中提到的那样,URI 和/或(不太理想(cookie 在每个请求中包含所有需要的信息。所以CurrentUser有点黑客。

随着转换的进展,您可能还会发现这个有趣的阅读:RESTful 服务中的非 CRUD 操作