Operazioni non CRUD in un servizio RESTful (WebAPI)

Question

Sto imparando WebAPI (e REST in generale) convertendo un servizio WCF esistente in WebAPI. Nel processo, sto diventando confuso sul modo migliore per gestire le operazioni non CRUD. Qui è il mio Contratto di servizio:

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

Alcuni dei metodi, come DeleteProxy, e AddProxy posso facilmente passare a una metodologia CRUD-based.

Le domande sorgono intorno:

GetProxyData - Il sistema di proxy viene utilizzato da più applicazioni, e anche se ho potuto fare api/Proxy/1, mi sento che è "barare", perché che dovrebbe essere per ottenere proxyid 1, non Proxy per l'applicazione 1.

GetUsersCurrentUserCanActAsProxyFor - Questo per me è fonte di confusione su più livelli. Come dovrei gestire più parametri? E non sta cadendo ordinatamente nel metodo CRUD, neanche.

Ciò significa che dovrei abbandonare la conversione WebAPI? In caso negativo, come dovrei affrontare questi metodi non standard?

Answer 1

Penso che tu stia confondendo i servizi RESTful con CRUD. I due non sono gli stessi, anche se il punto è chiaro che convertire CRUD in REST è abbastanza semplice (sia la risorsa che il verbo hanno una mappatura chiara).

Il più grande elemento di differenziazione di un'architettura RESTful è che è orientato alle risorse. Il secondo è che sfrutti il ​​protocollo dei trasporti (HTTP) per agire su quelle risorse - nel caso di REST che è GET, POST, PUT e DELETE.

Passando al tuo esempio, sembra che il tuo problema più grande sia la decisione sullo schema URI da utilizzare a supporto di questo servizio. Posso suggerire che per le informazioni gerarchiche questo dovrebbe essere semplice. Ad esempio, i proxy di applicazione:

/application/<id>/proxies

E gli utenti utente corrente può rappresentare per delega:

/user/<id>/proxy-users o seconda del vostro stile /user/<id>/proxy/users

o qualcosa di simile. Pensi alla relazione e alla risorsa sottostante. Molti URI possono puntare alla stessa risorsa.

Nota che come @dtb menziona nel suo commento l'URI e/o (meno preferibilmente) i cookie contengono tutte le informazioni necessarie in ogni richiesta. Quindi CurrentUser è un po 'un trucco.

È inoltre possibile trovare questa lettura interessante, come si procede nella vostra conversione: Non-CRUD operations in a RESTful service