Operacje inne niż CRUD w usłudze RESTful (WebAPI)

Question

Uczę się interfejsu WebAPI (i ogólnie usługi REST), konwertując istniejącą usługę WCF do interfejsu WebAPI. W trakcie tego procesu jestem coraz bardziej zdezorientowany, jeśli chodzi o najlepszy sposób na obsługę operacji niezawierających CRUD. Oto moja Umowa serwisowa:

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

Niektóre z metod, takich jak DeleteProxy i AddProxy można łatwo przenieść do metodyki opartej na CRUD.

pytania pojawiają się wokół:

GetProxyData - System proxy jest używany przez wiele aplikacji i choć mogłem zrobić api/Proxy/1, czuję, że to "oszustwo", ponieważ to powinno być dla coraz ProxyId 1, nie Proxy do Aplikacji 1.

GetUsersCurrentUserCanActAsProxyFor - Ten jest dla mnie dezorientujący na wielu poziomach. Jak mam obsługiwać wiele parametrów? I nie jest to również zgrabna metoda CRUD.

Czy to oznacza, że ​​powinienem zrezygnować z konwersji WebAPI? Jeśli nie, w jaki sposób mam rozwiązać te niestandardowe metody?

Answer 1

Myślę, że mylące usługi RESTful z CRUD. Oba nie są takie same, chociaż oczywiste jest, że konwersja CRUD na REST jest dość prosta (zarówno zasób, jak i czasownik mają wyraźne odwzorowanie).

Największy wyróżnik architektury REST jest taki, że jest zorientowany na zasoby. Drugi polega na tym, że wykorzystujesz protokół transportowy (HTTP) do działania na tych zasobach - w przypadku REST, który jest GET, POST, PUT i DELETE.

Przeprowadzając się do przykładu, wydaje się, że największym problemem jest wybór schematu URI do użycia w celu obsługi tej usługi. Mogę zasugerować, że dla informacji hierarchicznej powinno to być proste. Na przykład proxy aplikacyjne:

/application/<id>/proxies

a użytkownicy bieżący użytkownik może działać jako serwer proxy dla:

/user/<id>/proxy-users lub w zależności od stylu /user/<id>/proxy/users

lub coś podobnego. Myślisz o związku i bazowym zasobie. Wiele identyfikatorów URI może wskazywać na ten sam zasób.

Należy zauważyć, że jak @dtb wspomina w swoim komentarzu, URI i/lub (mniej korzystnie) pliki cookie zawierają wszystkie potrzebne informacje w każdym żądaniu. Więc CurrentUser to trochę hack.

Można również znaleźć ciekawe lektury miarę postępów w konwersji: Non-CRUD operations in a RESTful service