un soggiorno riposante risorsa Singleton

Question

vengo dal mondo RPC ma attualmente indagando se si utilizza REST è una buona idea per il mio progetto. Per quanto ne so dal Wikipedia l'idea di base dei servizi RESTful è quella di fornire accesso alle collezioni e ai loro singoli elementi.

Nel mio caso il server sarebbe uno strumento di misura. Devo essere in grado di avviare, interrompere e sospendere la routine di misurazione e leggere i dati in qualsiasi momento.

Attualmente, sto considerando la seguente:

• POST/misura (iniziare la misurazione, questo continuerà fino all'arresto da parte dell'utente)
• PUT/misura pausa = true/false (sospendere/riattivare)
• DELETE/misura (stop)
• GET/misura (Ottenere dati di misura)

Tuttavia, non sono sicuro se questo si inserisce il modello REST, dal momento che non ho davvero lavorare con le collezioni o elementi qui.

La mia domanda: Come potrei accedere a una risorsa Singleton e fare la start/stop richieste al server rompere il vincolo apolidi RESTful?

Answer 1

si sta ancora lavorando su una risorsa, e il modo in cui hai rotto il basso suona bene a me. Fielding menziona esplicitamente i servizi temporarali nello REST chapter:

L'astrazione chiave delle informazioni in REST è una risorsa. Qualsiasi informazioni che può essere nominato può essere una risorsa: un documento o un'immagine, un servizio temporale (ad esempio, "Il tempo oggi a Los Angeles")

Forse avrebbe senso per dare ad ogni misura di un ID univoco però . In questo modo puoi riferirti in modo univoco a ogni misurazione (non devi nemmeno memorizzare quelli vecchi, ma se qualcuno fa riferimento a una vecchia misurazione puoi dire loro che ciò che stanno richiedendo non è più aggiornato).

Answer 2

Basandosi sulle l'ultima risposta. Ecco come si potrebbe desiderare di scomposizione

• misure/- GET tutte le misure dallo strumento (Impagina/limite, se necessario, sulla base di query params)
• misure /: measure_id - GET una particolare misura
• misure/- POST - Avvia una nuova misura. Questo restituisce il nuovo ID della misura che puoi gestire in seguito.
• misure /: measure_id - DELETE - interrompe la misura.
• misure /: measure_id - PUT - aggiorna la misura
• misure/last_measure - Ultima risorsa misurata.

Answer 3

Non RESTful

No, il tuo approccio non è riposante, perché se ho ben capito il flusso di lavoro, si dovrebbe eliminare la risorsa per fermare la misurazione e quindi ottenere la risorsa di leggere il risultato finale. Ma l'eliminazione di una risorsa implica che non sarebbe rimasto nulla a GET.

Il fatto che la risorsa sia un singleton non è affatto un problema. Il problema sta nel modo in cui stai mappando i verbi e lo stato.

La tua descrizione è un po 'astratta, quindi cerchiamo di essere un po' più concreti: supponiamo che lo strumento in questione misura la velocità angolare di una ruota in radianti/sec. Questo strumento ha alcuni costi associati alla misurazione, pertanto il client deve essere in grado di disabilitare la misurazione per alcuni periodi di tempo come misura di risparmio dei costi. Se questo è approssimativamente analogo al tuo scenario, allora l'esposizione qui sotto dovrebbe essere applicabile al tuo scenario.

Verbi

Ora, esaminiamo i vostri verbi.

GET restituisce una rappresentazione di una risorsa. Pertanto, quando si utilizza lo standard GET /measure, è necessario restituire alcuni dati che rappresentano la misurazione corrente.

PUT crea o aggiorna una risorsa specifica denominata. La risorsa è nominata dal suo URL. Quindi, PUT /measure implica che si sta aggiornando lo stato di una risorsa denominata /measure o che si sta creando tale risorsa se non esiste già. Nel tuo caso, il valore dello strumento è di sola lettura: non possiamo scrivere un valore di radianti/sec sullo strumento. Ma la pausa/attivo stato dello strumento è mutevole, così PUT /measure dovrebbe includere un corpo che modifica lo stato dello strumento. È possibile utilizzare molte rappresentazioni diverse qui, ma un approccio semplice potrebbe essere un corpo di richiesta come active=true o active=false per indicare quale dovrebbe essere il nuovo stato dello strumento.

POST è simile a PUT, tranne che il client non specifica il nome della risorsa che deve essere creata o aggiornata. Ad esempio, in un'API diversa, il client potrebbe POST /articles per creare un nuovo articolo. Il server creerebbe una risorsa e gli assegnerà un nome come /articles/1234 e quindi dirà al client di questo nuovo nome restituendo un codice HTTP 201 CREATED e aggiungendo un'intestazione Location: /articles/1234 per comunicare al client dove si trova la nuova risorsa. Nel tuo scenario, POST non è un verbo significativo perché sai sempre qual è il nome della tua risorsa singleton.

DELETE significa che si rimuove una risorsa e poiché una risorsa è identificata da un URL, DELETE /measure implica che non esiste più. Un successivo GET /measure deve restituire 404 NOT FOUND o 410 GONE. Nel tuo caso, il client non può effettivamente distruggere lo strumento, quindi DELETE non è un verbo significativo.

Conclusione

Quindi, in sintesi, un design RESTful per il vostro servizio sarebbe quello di avere PUT /measure con un corpo della richiesta che racconta lo strumento se deve essere attivo o non attivo (pausa) e GET /measure per leggere la misura della corrente .Se si utilizza lo strumento in pausa GET /measure, è consigliabile restituire uno stato HTTP 409 CONFLICT. Il servizio non deve utilizzare POST o DELETE.