Transizioni di stato con informazioni aggiuntive nelle interfacce RESTful

Question

Transizioni di stato con informazioni aggiuntive nelle interfacce RESTful

#1 da (1 voti)
#2 da (0 voti)

3

Come progetteresti un'interfaccia REST che innesca un cambio di stato di un oggetto, ma richiede proprietà aggiuntive in quel momento? Ad esempio, il deliverer di un pacchetto deve cambiare lo stato del pacchetto da in transport a deliver , ma anche specificare come è stato consegnato (letterbox o di persona).

Vedo due possibilità:

POST /packages/:id/deliver con deliveredTo come corpo richiesta
PATCH /packages/:id con status=delivered&deliveredTo=... come corpo richiesta

In genere è consigliabile utilizzare i metodi POST , PUT o PATCH per aggiornare lo stato delle risorse in un'API RESTful. Le azioni in stile RPC dovrebbero essere evitate.

Il problema che vedo con il secondo approccio è che la convalida è difficile. Il POST /packages iniziale non deve accettare il campo deliveredTo , ma la richiesta PATCH che include status=delivered lo richiede. Questo non è solo complicato da implementare (in genere non è supportato dai framework), ma rende anche complicata l'API.

Quindi questo è un caso in cui le azioni personalizzate sono appropriate?

api-design rest

posta Yogu 30.06.2015 - 11:38

fonte

2 risposte

0

REST interessa una singola risorsa, non significa che puoi aggiornare solo una singola proprietà su quella risorsa.

Alcune interfacce RESTful (ad es. SMTP) hanno un singolo sistema di inserimento di proprietà, in cui si chiama ripetutamente un verbo personalizzato con una singola proprietà fino a quando la risorsa non è completamente popolata con tutti i dati. Altri inviano un blob di dati in un singolo pacchetto (XML, stringa di query, dati del modulo, non importa quale) per aggiornare tutte le proprietà in un colpo solo.

Penso che la distinzione di cui usare dipende dalla latenza del tuo canale di comunicazione - quindi chiamare un'interfaccia REST su http è piuttosto lento, quindi dovresti inviare tutte le proprietà in un singolo messaggio.

risposta data 30.06.2015 - 13:14

fonte

Leggi altre domande sui tag api-design rest

Dove memorizzare le impostazioni globali configurabili Dividi il programma in programmi più piccoli

score 1 · Accepted Answer

Ti aiuterebbe ad avere più risorse?

/ packages / 12345 / Stato
/ packages / 12345 / Stato / ultima
/ packages / 12345 / stato / versioni / 7
/ packages / 12345 / stato? A = 20150630T1138-0600
/ packages / 12345 / storia / consegna / Stato
/ packages / 12345 / storia / ultima / Stato
/ paclages / 12345 / storia / 20.150.630 / aggiornamenti / 2

Ceci n'est-pas un package. Diversi casi d'uso possono utilizzare identificatori diversi per manipolare "gli stessi" dati.

In altre parole, è un identificatore di risorsa uniforme, non un identificatore di entità di dominio uniforme. Avere molte risorse che rappresentano una singola entità ti offre molta flessibilità.

Riferimenti

Le specifiche di PUT in RFC 2616 supportano la nozione che una singola risorsa può rappresentata da più di un URI

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

Questa lingua è sostanzialmente cambiata in RFC 7231

A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.

Temi di Fielding ha questo da dire

For example, the “authors’ preferred version” of an academic paper is a mapping whose value changes over time, whereas a mapping to “the paper published in the proceedings of conference X” is static. These are two distinct resources, even if they both map to the same value at some point in time. The distinction is necessary so that both resources can be identified and referenced independently.