我通过将现有的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的Proxies.
GetUsersCurrentUserCanActAsProxyFor – 这个对我来说在多个层面上令人困惑.我该如何处理多个参数？并且它也没有完全落入CRUD方法.
这是否意味着我应该放弃WebAPI转换？如果没有,我该如何处理这些非标准方法？
解决方法
我认为你将RESTful服务与CRUD混淆了.这两者并不相同,尽管很明显将CRUD转换为REST非常简单(资源和动词都有明确的映射).
RESTful架构的最大区别在于它是面向资源的.第二个是你利用传输(HTTPs)协议来处理这些资源 – 对于REST的GET,POST,PUT和DELETE.
转到您的示例,似乎您最大的麻烦是决定使用URI方案来支持此服务.我可以建议,对于分层信息,这应该是直截了当的.例如,应用程序代理：
/应用/< ID> /代理
/ user /< id> / proxy-users或取决于您的样式/用户/< id> / proxy / users
或类似的东西.您会想到关系和底层资源.许多URI可以指向相同的资源.
请注意,虽然@dtb在他的评论中提到URI和/或(不太优选)cookie包含每个请求中的所有所需信息.所以CurrentUser有点像黑客.
在转换过程中,您可能会发现这个有趣的读物：Non-CRUD operations in a RESTful service
