Question

我正在通过将现有的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转换？如果没有，我该如何处理这些非标准方法？

Answer 1

我认为你将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有点像黑客。

您可能会在转化过程中找到这个有趣的读物：Non-CRUD operations in a RESTful service

RESTful（Web API）服务中的非CRUD操作

1 个答案: