Question

I’m learning WebAPI (and REST in general) by converting an existing WCF service to WebAPI. In the process, I’m becoming confused as to the best way to handle the non-CRUD operations. Here is my Service Contract:

[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);
}

Some of the methods, like DeleteProxy, and AddProxy I can easily move to a CRUD-based methodology.

The questions arise around:

GetProxyData – The proxy system is used by multiple applications, and though I could do api/Proxy/1, I feel that’s “cheating” because that should be for getting ProxyId 1, not Proxies for Application 1.

GetUsersCurrentUserCanActAsProxyFor – This one is confusing on multiple levels for me. How should I handle multiple parameters? And it’s not falling neatly into the CRUD method, either.

Does this mean I should abandon the WebAPI conversion? If not, how should I tackle these non-standard methods?

Answer 1

I think you’re confusing RESTful services with CRUD. The two are not the same, although the point is clear that converting CRUD to REST is quite straightforward (both the resource and the verb have a clear mapping).

The greatest differentiator of a RESTful architecture is that it is resource oriented. The second is that you leverage the transports (HTTPs) protocol to act on those resources – in the case for REST that’s GET, POST, PUT and DELETE.

Moving to your example, it seems as though your biggest trouble is deciding on the URI scheme to use in support of this service. May I suggest that for hierarchical information this should be straightforward. For example, application proxies:

/application/<id>/proxies

And the users current user can act as proxy for:

/user/<id>/proxy-users or depending on your style /user/<id>/proxy/users

Or something similar. You think of the relationship and underlying resource. Many URIs can point to the same resource.

Note though that as @dtb mentions in his comment the URI and/or (less preferably) cookies contain all needed information in every request. So CurrentUser is a bit of a hack.

You may also find this interesting reading as you progress in your conversion: Non-CRUD operations in a RESTful service