raccomandazioni riguardanti la risorsa uri

Question

raccomandazioni riguardanti la risorsa uri

#1 da (3 voti)

2

diciamo che abbiamo una "door api" e voglio creare una risorsa per chiudere la porta.

Potrei farlo in 3 modi:

modo tradizionale usando PUT con payload {id: XX, colore: YY, chiuso: vero}
- vantaggi: semplice e segue lo standard
- svantaggi: il client deve modificare l'istanza della porta modificando la proprietà chiusa e inviando il valore al back-end. Se la richiesta non riesce, il client deve ripristinare il valore originale.
modo tradizionale con PATCH con payload {closed: true}
- vantaggio: semplice e riduce il carico utile al minimo
- svantaggi: come PUT
creare una risorsa / porta / porta chiusa / {porta id} con PUT?
- vantaggi: il codice cliente è semplice, basta chiamare la risorsa e devi solo modificare l'oggetto porta sul client se la richiesta ha esito positivo
- svantaggi: non sono sicuro se questo sia il modo giusto per creare un URI di risorse

DOMANDA 1: qualcuno potrebbe aiutarmi a capire qualsiasi svantaggio dell'opzione 3 (che è la mia preferita) e in caso di problemi con quell'URI?

DOMANDA 2: Credo che dovrei usare verbo PUT sull'opzione 3 ... ha senso avere PUT senza payload?

grazie

api-design api rest resources uri

posta Manuel Sopena Ballesteros 08.08.2018 - 15:48

fonte

1 risposta

Leggi altre domande sui tag api-design api rest resources uri

Definire sensibilmente una query complessa in JSON Wikipedia Store ogni pagina di modifica? [chiuso]

score 3 · Accepted Answer

Parte del punto di REST è che i client sono isolati dai dettagli di implementazione.

In altre parole: non dovresti essere in grado di dire se la porta è davvero solo un documento o una raccolta di sensori e attuatori.

QUESTION: could someone please help me to understand any disadvantage of option 3 (which is my favourite one) and if any issue with that URI?

Non c'è niente di sbagliato nell'URI - resto non interessa quali sono gli ortografie che usi per i tuoi identificatori.

Si preoccupa, in qualche modo, quando usi gli identificatori diversi ; per quanto riguarda HTTP, diversi identificatori sono diversi, il che significa che non c'è interazione tra loro nella cache.

Cioè, se metto in cache la risposta a

GET /door/12345

Quindi i metodi sicuri sicuri con quell'obiettivo di richiesta invalidano la rappresentazione che ho nella cache - questo è parte di ciò che significa essere insicuri. Vedi Hypertext Transfer Protocol (HTTP / 1.1): Caching , Invalidation (sezione 4.4).

PUT /door/12345
PATCH /door/12345
POST /door/12345

invaliderà tutti i risultati precedentemente memorizzati nella cache.

POST /door/12345/close-door
POST /door/close-door/12345
PUT  /door/close-door/12345

Queste richieste non invalideranno la rappresentazione precedente, perché la destinazione della richiesta non è la stessa.

does it makes sense to have PUT without payload?

Non c'è niente di sbagliato in questo.