Come si implementano i moduli di “modifica” delle risorse in modo RESTful?

Question

Stiamo cercando di implementare un'API REST per un'applicazione che abbiamo ora.Vogliamo esporre funzionalità di lettura/scrittura per varie risorse utilizzando l'API REST.Come implementiamo la parte "forma" di questo?Ottengo come esporre la "lettura" dei nostri dati creando URL RESTful che funzionano essenzialmente come chiamate di metodo e restituiscono i dati:

GET /restapi/myobject?param=object-id-maybe

...e viene restituito un documento XML che rappresenta una struttura dati.Bene.

Ma, normalmente, in un'applicazione web, una "modifica" comporterebbe due richieste:uno per caricare la versione corrente delle risorse e compilare il modulo con tali dati e uno per pubblicare nuovamente i dati modificati.

Ma non capisco come faresti la stessa cosa con i metodi HTTP su cui REST è in qualche modo mappato.È un PUT, giusto?Qualcuno può spiegarlo?

(Ulteriore considerazione:L'interfaccia utente verrebbe eseguita principalmente con AJAX)

-- Aggiornamento:Questo sicuramente aiuta.Ma sono ancora un po' confuso riguardo al lato server?Ovviamente qui non mi sto occupando semplicemente di file.Sul server, il codice che risponde alle richieste dovrebbe filtrare il metodo di richiesta per determinare cosa farne?È questo il "passaggio" tra letture e scritture?

Answer 1

Se invii i dati tramite semplice HTML, sei limitato a creare un modulo basato su POST.L'URI a cui viene inviata la richiesta POST non dovrebbe essere l'URI per la risorsa da modificare.Dovresti eseguire il POST su una risorsa di raccolta che AGGIUNGE ogni volta una risorsa appena creata (con l'URI per la nuova risorsa nel Posizione intestazione e a 202 codice di stato) o POST su una risorsa di aggiornamento che aggiorna una risorsa con un URI fornito nel contenuto della richiesta (o intestazione personalizzata).

Se utilizzi un oggetto XmlHttpRequest, puoi impostare il metodo su PUT e inviare i dati all'URI della risorsa.Questo può funzionare anche con moduli vuoti se il server fornisce un URI valido per la risorsa ancora inesistente.Il primo PUT creerebbe la risorsa (returning 202).I PUT successivi non faranno nulla se si tratta degli stessi dati o modificheranno la risorsa esistente (in entrambi i casi a 200 viene restituito a meno che non si verifichi un errore).

Answer 2

Esistono molte alternative diverse che puoi utilizzare.Una buona soluzione è fornita al wiki sui microformati ed è stato anche referenziato dal team RESTful JSON.Il più vicino possibile a uno standard, davvero.

 Operate on a Record

GET /people/1
    return the first record 
DELETE /people/1
    destroy the first record 
POST /people/1?_method=DELETE
    alias for DELETE, to compensate for browser limitations 

GET /people/1/edit
    return a form to edit the first record 
PUT /people/1
    submit fields for updating the first record 
POST /people/1?_method=PUT
    alias for PUT, to compensate for browser limitations 

Answer 3

Penso che sia necessario separare i servizi dati dall'interfaccia utente web.Quando si forniscono servizi dati, un sistema RESTful è del tutto appropriato, compreso l'uso di verbi che i browser non possono supportare (come PUT e DELETE).

Quando si descrive un'interfaccia utente, penso che la maggior parte delle persone confonda "RESTful" con "URL carini e prevedibili".Non sarei poi così preoccupato per una sintassi URL puramente RESTful quando descrivi l'interfaccia utente web.

Answer 4

Il caricamento dovrebbe essere semplicemente una normale richiesta GET e il salvataggio di nuovi dati dovrebbe essere un POST sull'URL che attualmente contiene i dati...

Ad esempio, carica i dati correnti da http://www.example.com/record/matt-s-example quindi modificare i dati e eseguire nuovamente il POST sullo stesso URL con i nuovi dati.

Una richiesta PUT potrebbe essere utilizzata durante la creazione di un nuovo record (ad es.METTERE i dati in un URL che attualmente non esiste), ma in pratica solo il POST è probabilmente un approccio migliore con cui iniziare.