Un modo RESTful per verificare lo stato del server [chiuso]

Supponendo che dovresti chiedere la stessa verifica due volte di seguito. Avresti la stessa risposta? Inciderebbe in modo significativo lo stato delle risorse? Se si ottiene logicamente la stessa risposta (che non ha bisogno di essere identica al byte, ma piuttosto "uguale" in senso più elevato) e non influenzerà lo stato delle risorse in alcun significato in questo modo un GET produce una enorme quantità di senso. Ciò a sua volta significa che qualsiasi parametro che passi sarà codificato nel percorso o come parametri di query. Tutto ciò mi sembra molto ragionevole.

Quale sarebbe la risposta? Beh, sarei tentato di dire almeno di prendere in considerazione rendendolo sempre 200 e di avere il documento di risposta che descrive ciò che è passato o fallito: almeno su un livello, stai recuperando con successo un documento che descrive cosa è successo, anche se è una descrizione di un fallimento.

Si potrebbe anche modellare un errore come uno degli errori della serie 500 (salvare la serie 400 per problemi di "richiesta errata", come il passaggio di parametri di query privi di senso) in quanto il problema sarebbe lo stato del servizio, non il cliente. Ma sinceramente non lo raccomanderei veramente; un errore di convalida non è colpa del servizio in quanto tale, ma piuttosto solo alcuni dati sfortunati che il servizio è stato affidato a cura. (A livello operativo, la procedura di convalida ha avuto successo, ma i dati non erano validi. È come un famoso detto del chirurgo: l'operazione è stata un successo, ma il paziente è morto.)

In nessuna circostanza restituirò 204 No Content da una convalida. È sempre migliore per inviare un messaggio indietro dicendo almeno un riassunto di ciò che è stato controllato; il cliente può buttarlo via se lo desidera, ma in linea di principio dovrebbe essere in grado di mostrare le informazioni all'utente.

Quando elabori la risposta da utilizzare, ricorda che qualsiasi servizio web RESTful dovrebbe essere utilizzabile da un normale browser Web con Javascript disabilitato (sebbene con capacità che la maggior parte dei browser reali normalmente non abilitano, per essere onesti) almeno in linea di principio . Le risposte agli errori dovrebbero quindi essere quelle utilizzate per questo tipo di finalità in una normale interazione web e ciò limita enormemente ciò che si può fare con gli errori della serie 400, poiché la maggior parte ha azioni di recupero del client molto stilizzate.

Non capisco esattamente il tuo esempio specifico, ma cercherò comunque di dare il mio consiglio.

REST riguarda esclusivamente le entità, lo stato e le transizioni di stato. Sembra quasi che quello che vuoi fare sia una query per qualche stato. Diamo un'occhiata ai verbi HTTP comuni:

POST - Comunemente utilizzato per creare uno stato aggiuntivo sul server.

PUT - Comunemente usato per creare o aggiornare lo stato esistente sul server.

DELETE - Utilizzato per eliminare alcuni stati dal server.

I metodi sopra riportati non hanno senso per il controllo dello stato esistente, che si vuole fare. Ho omesso CONNECT, TRACE e OPTIONS, poiché anche quelli non sembrano appropriati qui.

GET - Utilizzato per ottenere lo stato dal server.

HEAD - Come GET ma restituisce solo i metadati.

Quindi sembra che GET o HEAD siano i più appropriati, a seconda di dove si stanno restituendo le informazioni (nei metadati o nell'entità / corpo). Dal momento che non stai trasferendo lo stato sul server, ma interrogandoli, forse dovrebbe essere la responsabilità del client che fa l'asserzione di farlo invece del server che fa asserzioni.

Se vuoi sfruttare i codici di errore HTTP, forse potresti aggiungere un parametro di query. Ad esempio, post HEAD? Min_posts = 5 potrebbe restituire 404 (non trovato) se non ci sono post che soddisfano tale requisito. Altrimenti potrebbe restituire 204 (Nessun contenuto) se soddisfa il requisito.

Se non vuoi usare GET o HEAD, puoi provare a usare POST, ma questo richiede che tu crei qualche entità che rappresenti lo stato che stai postando, es. un'entità "asserzione". Potrebbe restituire 409 (Conflitto) se l'asserzione fallisce, poiché lo stato della risorsa nella richiesta (cioè l'asserzione) ha un conflitto (cioè non è vero o non è passato). Se l'asserzione passa, è possibile restituire 204 (nessun contenuto). Questo approccio mi sembra un trucco per me, comunque. Ma potrebbe effettivamente avere senso, a seconda dei dettagli del tuo sistema.

Voglio anche aggiungere che un'API "REST" viene raramente implementata correttamente. A volte a causa di compromessi accettabili / pratici dalle linee guida REST. Altre volte a causa dell'ignoranza di ciò che significa REST.

Non sono a conoscenza delle migliori pratiche per questo.

Quello che vorrei fare è inviare le asserzioni come intestazione di richiesta personalizzata con la normale richiesta.

X-ASSERTION min_posts=5 .

Quindi prima sul server analizzare l'intestazione ed elaborare le asserzioni e, a seconda del risultato, restituire l'errore HTTP (come proposto in un'altra risposta 204 No Content, 409 Conflict o altro più appropriato) o il risultato della richiesta.

Ulteriori informazioni sul risultato dell'asserzione potrebbero essere restituite come intestazione personalizzata nelle intestazioni di risposta.

STATUS 409 Confilct; X-ASSERTION-RESULT min_posts=3

Penso che questo sarebbe conforme ai principi REST, in quanto l'asserzione in realtà si sta scambiando i metadati (dati sui dati) e il posto per i metadati è nell'intestazione.

Tuttavia, in pratica, ciò potrebbe essere inaffidabile o difficile da implementare in quanto molti firewall o server di hosting condiviso eliminerebbero le intestazioni personalizzate.