Il REST può in pratica essere senza stato?

Question

Considerare la situazione.

Sto scrivendo un'app di analisi statistica. L'app ha più livelli.

1. Frontend UI scritto per più tipi di dispositivi, desktop del browser, mobile.
2. Servlet di livello intermedio che offre un cosiddetto servizio REST a questi frontend.
3. Backend che esegue il calcolo estremo dell'elaborazione statistica .
4. che comunica con un ulteriore database back-end

dovuto il motivo che l'analisi statistica richiede enormi quantità di potenza di elaborazione, si sarebbe mai sognato di delegare tale trattamento al front-end.

1. Le analisi statistiche costituito da procedure o una serie di passaggi work-flow.

2. Alcuni passaggi potrebbero richiedere tanta potenza di elaborazione, non si vorrebbe che li ripeta.

3. Se ha un flusso di lavoro di 20 passi, non è possibile eseguire il punto 20 senza prima di eseguire il punto 19, che non può essere eseguita senza prima di eseguire il punto 18, così via e così via.

4. Ci sono punti di osservazione, in modo tale che, per esempio, lo statistico deve ispezionare risultati delle fasi 3, 7, 9, 14, 19 prima dice di lato client per procedere al passo successivo.

5. Ciascuno di questi passaggi sono un cosiddetto richiesta al servizio REST, per dire il supercomputer back-end per impostare progressivamente il modello statistico in memoria.

6. Ci sono molti flussi di lavoro. Alcuni flussi di lavoro possono incidentalmente condividere i risultati del passaggio . ad es. Flusso [secco]: il passaggio [7] può condividere Flusso [bagnato]: Passaggio [10]. A causa di per la quantità di elaborazione coinvolta, abbiamo assolutamente impedito ripetendo un passaggio che potrebbe già essere stato compiuto da un altro flusso.

Pertanto, si può vedere che nel cosiddetto servizio REST in fase di progettazione, non è possibile che ogni richiesta sia indipendente da qualsiasi richiesta precedente.

Pertanto, quanto può essere vera la seguente affermazione?

Tutte le interazioni REST sono senza stato. Cioè, ogni richiesta contiene tutte le informazioni necessarie per un connettore per comprendere la richiesta , indipendentemente da eventuali richieste che potrebbero averlo preceduto.

Ovviamente, l'applicazione che ho descritto richiede che la richiesta dipenda dalla richiesta precedente. Ci sono tre possibilità che posso vedere riguardo questa app.

• La mia app non è conforme a REST, poiché non è in grado di soddisfare le richieste stateless. Può usare il framework JAX-RS, ma usare JAX-RS e tutti i crear di REST non lo rende REST, semplicemente perché fallisce il criterio stateless.
• La mia app è progettata male - dovrei ignorare il tentativo di evitare i costi temporali e finanziari reimballando un modello statistico anche se ci sono voluti 5 - 15 minuti per un flusso di lavoro. Assicurati solo che non ci sia dipendenza dalle richieste precedenti. Ripeti i passaggi costosi quando necessario.
• I criteri di apolidi sono obsoleti. La mia comprensione del REST è obsoleta/difettosa in quanto la comunità REST ha costantemente ignorato questo criterio.

La mia app è considerata RESTful?

nuova domanda: ISO 9000

Infine, nel caso in cui la mia applicazione non è completamente considerato riposante, avrebbe tutti i riferimenti a "riposo" deve essere omesso per passare la certificazione ISO 9000?

nuovo edit:

REST-in-pezzo

OK, il mio collega ed io abbiamo discusso di questo e ha deciso di chiamare ad un'architettura/modello REST-in-pezzo = REST a tappe graduali .

Answer 1

ISTM, stai leggendo troppo per l'apolidia. Un'API REST supporta il tradizionale CRUD operations. L'API per CouchDB è un buon esempio di come lo stato DB viene aggiornato da una serie di transazioni senza stato.

Il tuo compito è identificare quali sono le risorse e lo "stato trasferisce" tra loro. Ogni passaggio nel flusso di lavoro è un diverso trasferimento di stato, contrassegnato da un URI diverso. Ogni aggiornamento/modifica di una risorsa ha un POST/PATCH accompagnatorio o un'operazione PUT o DELETE idempotente.

Se si desidera ottenere una migliore comprensione di cosa significa essere RESTful e le ragioni di ciascuna scelta di progettazione, si consiglia di passare un'ora leggendo Chapter 5 of Roy Fielding's Dissertation.

Quando si effettuano scelte di progettazione, basta pensare a quali sono i principi del design RESTful che si stanno cercando di realizzare. Configura il tuo progetto in modo che le query siano sicure (non cambiare stato) e che siano fatte in un modo che possa essere bookmarkable, memorizzabile in cache, distribuibile, ecc. Ogni passaggio nel flusso di lavoro passi a un nuovo stato con un URI distinto che un utente può eseguire il backup, espandersi in modi diversi, ecc. L'idea è di creare un design flessibile e scalabile.

Answer 2

Si sta aggiornando un modello in memoria tramite un REST api. Ciò significa che stai mantenendo lo stato sul server tra le richieste.

Il modo migliore per risolvere questo problema consiste nel far sì che il client mantenga lo stato semplicemente elaborando la richiesta e restituendo tutte le informazioni per la costruzione della richiesta successiva nella risposta. Il server quindi ricostruisce il modello in memoria dalle informazioni nella richiesta e quindi fa il suo dovere. In questo modo, se operi ad es.un ambiente cluster, qualsiasi server disponibile sarebbe in grado di gestire la richiesta.

Se questo è il modo più efficace per fare le cose dipende dalla vostra applicazione. Esistono numerose applicazioni aziendali che utilizzano una sessione lato server ed elaborano il bilanciamento del carico per garantire che i client utilizzino sempre gli stessi nodi in un cluster. Quindi avere lo stato lato server è una scelta progettuale del tutto valida e ci sono molti modi per implementarlo in modo efficace. Tuttavia, lo stato lato server generalmente complica il ridimensionamento e REST nel senso più puro consiste nell'evitare lo stato lato server ed evitare la complessità.

Una soluzione/compromesso sta persistendo lo stato in una sorta di database o archivio. In questo modo i tuoi nodi possono recuperare lo stato dal disco prima di elaborare una richiesta.

Tutto dipende da ciò che è necessario e ciò che è accettabile per voi. Come il precedente commentatore ha menzionato, non ti aggredire troppo per questa cosa dello stato di cose. Chiaramente qualcuno dovrà mantenere lo stato e la domanda è semplicemente quale sia il posto migliore per metterti questo stato e come accedervi. Fondamentalmente ci sono un paio di compromessi che fondamentalmente hanno a che fare con vari scenari di tipo what-if. Ad esempio, se il server si blocca, vuoi che il client riesegua l'intero set di richieste per ricostruire il calcolo o preferisci semplicemente inviare nuovamente l'ultima richiesta? Posso immaginare che non hai davvero bisogno di alta disponibilità qui e non preoccuparti del basso rischio che qualcosa possa occasionalmente andare storto per i tuoi clienti. In tal caso, avere lo stato sul lato server in memoria è una soluzione accettabile.

Supponendo che il server mantenga lo stato di calcolo in alcune mappe hash, un modo REST-pieno di passare lo stato intorno potrebbe semplicemente restituire la chiave per il modello nella risposta. Questa è un'API perfettamente efficiente e puoi cambiare l'implementazione per mantenere lo stato o fare qualcos'altro senza modificare l'API quando necessario. E questo è il punto principale di REST-ful: separare i dettagli di implementazione dall'API. Il tuo cliente non ha bisogno di sapere dove hai messo lo stato o come lo hai archiviato. Tutto ciò di cui ha bisogno è una rappresentazione delle risorse di quello stato che può essere manipolata.

Ovviamente la chiave deve essere rappresentata come un URI. Vi consiglio di leggere "REST in pratica" di Jim Webber. È un'ottima introduzione alla progettazione di API REST-ful.