Operaciones no CRUD en un servicio RESTful (WebAPI)

Question

Estoy aprendiendo WebAPI (y REST en general) al convertir un servicio WCF existente a WebAPI. En el proceso, me confundo la mejor manera de manejar las operaciones que no son de CRUD. Aquí está mi contrato de servicio:

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

Algunos de los métodos, como DeleteProxy y AddProxy que se puede mover fácilmente a una metodología basada en la ABM.

Las preguntas surgen en torno a:

GetProxyData - El sistema de proxy es utilizado por varias aplicaciones, y aunque lo que podía hacer api/Proxy/1, siento que es "hacer trampa", ya que debe ser para conseguir proxyid 1, no Proxies para la aplicación 1.

GetUsersCurrentUserCanActAsProxyFor - Esto confunde en varios niveles para mí. ¿Cómo debo manejar múltiples parámetros? Y tampoco está cayendo claramente en el método CRUD.

¿Significa esto que debería abandonar la conversión de WebAPI? Si no, ¿cómo debería abordar estos métodos no estándar?

Answer 1

Creo que está confundiendo los servicios RESTful con CRUD. Los dos no son lo mismo, aunque el punto es claro que la conversión de CRUD a REST es bastante sencilla (tanto el recurso como el verbo tienen un mapeo claro).

El mayor diferenciador de una arquitectura REST es que está orientado a recursos. El segundo es que aproveche el protocolo de transporte (HTTP) para actuar sobre esos recursos, en el caso de REST que es GET, POST, PUT y DELETE.

Pasando a su ejemplo, parece que su mayor problema es decidir sobre el esquema de URI para utilizar en apoyo de este servicio. Puedo sugerir que para información jerárquica esto debería ser sencillo. Por ejemplo, los proxies de aplicación:

/application/<id>/proxies

Y los usuarios de usuario actual puede actuar como proxy para:

/user/<id>/proxy-users o dependiendo de su estilo /user/<id>/proxy/users

o algo similar. Piensas en la relación y el recurso subyacente. Muchos URI pueden apuntar al mismo recurso.

Tenga en cuenta que como @dtb menciona en su comentario que el URI y/o (menos preferiblemente) las cookies contienen toda la información necesaria en cada solicitud. Entonces, CurrentUser es un truco.

También puede encontrar esta interesante lectura a medida que avanza en su conversión: Non-CRUD operations in a RESTful service