Nome / metodo migliore per un endpoint RESTful che riprende un processo batch

Questa è un'applicazione per stato, che è ciò che rappresenta la S in REST. I lavori batch di cui parli hanno uno stato autonomo, che li rende facili da modellare.

Assegna a ciascuno un state che, a seconda di quanto complesso vuoi farlo, potrebbe avere valori come questi:

• pending - Inviato ma non avviato.
• running - In esecuzione ma non completato.
• finished - Non è in esecuzione, ma è scaduto fino al completamento.
• abended - Non in esecuzione, terminato in modo anomalo e richiede il riavvio per il completamento.

Un client che desidera riavviare un lavoro ABENDed può PATCH della risorsa (o PUT se è indipendente, ad esempio /batch-job/12345/state ) e imposta lo stato su running . La reazione del sistema sarebbe vedere la transizione da abend a running e riavviarla dall'inizio.

Il codice dietro il tuo modello dovrà verificare che l'utente non faccia nulla di non valido, come forzare un finished di lavoro a pending .

Il sistema stesso dovrà assicurarsi che running jobs abbia i propri stati impostati correttamente su abend quando qualcosa va storto. Consiglierei di impostarli durante gli spegnimenti sia ordinari che all'avvio nel caso in cui il sistema si scarichi senza preavviso.

REST non ha convenzioni di denominazione, di per sé. L'idea è che i singoli URL facciano riferimento opaco a risorse specifiche, il cui stato può essere recuperato o aggiornato dai clienti. Detto questo, un modello comune per le risorse di lavoro è

• POST / job - > crea / restituisce una risorsa lavoro / $ / lavoro, ad es. nella posizione: intestazione
• GET / job / $ jobid - > ottenere dettagli sull'istanza di lavoro
• PATCH / job / $ jobid - > modifica la risorsa lavoro

Lo stato del lavoro è solitamente un campo nella risorsa. Per riavviare un lavoro, PATCH una modifica alla struttura dei dati delle risorse.

Una buona progettazione delle risorse lavorative può essere sottile, perché i lavori in genere hanno una macchina a stati di stati subordinati accettabili e un numero limitato di modi in cui il grafico di stato può essere attraversato. Per fornire la massima flessibilità, in genere si desidera rendere esplicita tale macchina di stato nella risorsa, ad es. con una coppia di campi - sotto-stato e stato - o anche una matrice di sotto-stato e stato. Rendere esplicita la macchina consente agli utenti di specificare qualsiasi cambiamento di stato che desiderano. È possibile rispondere alle modifiche di stato non valide con errori 4xx.

How should I name my endpoint while adhering to the REST naming conventions?

REST non si cura di quale ortografia si usa per gli identificatori di risorse.

Pensa a come dovresti lavorare con l'esercizio nel tuo browser web. Dovresti compilare un modulo e inviare il lavoro; torneresti una sorta di ricevuta, che includerebbe un link alla pagina di stato. Puoi caricare / aggiornare la pagina di stato per vedere come stanno andando le cose. Se il server è stato disattivato a metà elaborazione, il processo non avrebbe avuto esito positivo e la pagina di stato sarebbe stata aggiornata per riflettere ciò. Ad esempio, potresti trovare un modulo su quella pagina che, quando lo invii, riprende il lavoro.

In nessun momento di questo flusso, il cliente deve capire come si scrive un identificatore. Basta seguire i link e compilare i moduli.

That's REST.

/a216fc62-6e0b-44da-8744-c7a8b4aae043 è un identificatore perfettamente ragionevole per una risorsa che gestirà un messaggio.

Se è così, lo è anche: /batch-job/restart

Se vuoi che l'URI sia hackerabile , questo è anche bene - ma non è un vincolo REST. Ci sono buone ragioni per cui potresti voler rendere l'URI difficile da hackerare .

È assolutamente bene POSTARE un messaggio a un endpoint e fare in modo che l'endpoint capisca cosa fare in base al contenuto del corpo del messaggio. Quindi puoi avere un unico endpoint che gestisce più tipi di messaggi. Questo può essere davvero comodo perché il messaggio POST invalida la rappresentazione della risorsa memorizzata nella cache da qualsiasi partecipante che può leggi la richiesta e la risposta.

Ad esempio, poiché sai che la "risorsa della pagina di stato" sarà modificata dall'istruzione per riprendere il lavoro, potrebbe essere sensato inviare il messaggio di ripresa a quella risorsa.

Se sei disturbato dalla tranquillità di qualsiasi metodo POST, puoi semplicemente aggiungere la parola "richiesta" fino alla fine. ad es.

POST: batch-job/restart = BAD!

quando aggiungi la parola magica restia!

POST: batch-job/restartRequest = GOOD!

Funziona praticamente con qualsiasi cosa, perché puoi sempre POSTARE una richiesta!

* finché includi un timbro