modo RESTful ad accettare una scelta

Question

ho una semplice API, che funziona così:

1. Un utente crea una richiesta (POST /requests)
2. Un altro utente recupera tutte le richieste (GET /requests)
3. poi aggiunge un'offerta di una richiesta (POST /requests/123/offers)
4. utente originale può ora vedere tutte le offerte stati fatti per la richiesta (GET /requests/123/offers)

Quello che voglio fare è consentire all'utente iniziale di accettare una richiesta, ma non riesco a capire il modo migliore per farlo RESTfuly.

Devo farlo con il verbo PATCH? Come PATCH /requests/123 e richiede che il corpo della patch contenga un ID offerta valido?

Answer 1

Accettare un'offerta cinque volte dovrebbe avere lo stesso effetto di accettarla una volta. È idempotente. Quindi dovrebbe essere un PUT.

Si potrebbe voler prendere in considerazione la scelta di un nome diverso per le "richieste". Quando faccio GET /requests/123, richiedo una risposta che è una richiesta? Questo potrebbe essere un po 'di confusione per i clienti.

Inoltre, cercare di evitare di annidare i propri identificativi di risorsa. Questo può creare problemi per te in seguito. Un'offerta non deve essere necessariamente "sotto" la richiesta corrispondente. Cosa succede quando in seguito vuoi avere offerte corrispondenti a più richieste?

Una buona regola è, se si prenderebbe in considerazione "Gizmo" un'entità in un entity-relationship model, dovrebbe essere una radice a livello di URI, come in GET /gizmos/17, non GET /widgets/54/gizmos/17. Un errore comune è quello di dire "Ogni Gizmo ha esattamente un widget correlato, quindi dovrei annidare gli URI Gizmo come estensioni degli URI dei widget."

Di seguito ho un suggerimento su come sarebbero le operazioni. Potresti voler sostituire alcuni dei riferimenti ID con gli URI, ma dipende da te.

POST /requests   ---> 201 Created 
           Location: /requests/123 

GET /requests    ---> 200 OK 
           [ 
            { 
             "requestId": 123, 
             "offersUri": "/offers?requestId=123", 
             ... 
            }, 
            ... 
           ] 

POST /offers    ---> 201 Created 
{        Location: /offers/456 
    "requestId": 123, 
    "amount": 300, 
    ... 
} 

GET /offers?requestId=123 ---> 200 OK 
           [ 
            { 
             "requestId": 123, 
             "amount": 300, 
             ... 
            } 
           ] 

PUT /offers/456/approval ---> 204 No Content 
PUT /offers/456/approval ---> 204 No Content 
PUT /offers/456/approval ---> 204 No Content 

Answer 2

A seconda della natura dell'Accettazione.

Se Acceptance è un semplice attributo di un'offerta, POST l'offerta con l'Acceptance impostato su True.

Se l'accettazione è più complessa e quindi una risorsa a sé stante, metterei un'accettazione nell'offerta (PUT /requests/123/offers/acceptance).

Se esiste una cosa come un rifiuto, o una richiesta di chiarimento dell'offerta, potrei considerare la risorsa rilevante come una risposta, non un'accettazione, e PUT che (put /requests/123/offers/response).