Servizio Web e coda messaggi

Question

Servizio Web e coda messaggi

#1 da (6 voti)
#2 da (1 voti)
#3 da (1 voti)

4

Stiamo cercando di creare uno strato di servizi Web / API REST che verrà utilizzato dai client Web e mobili.

Per rendere la soluzione più solida stavo considerando di mettere i comandi da PUT, POST e PATCH su una coda di messaggi, il che significherebbe che sarebbero poi eseguiti in modo asincrono.

Esiste una risposta HTTP standard da un'API RESTful che indica che un comando verrà eseguito in modo asincrono?

Modifica

In realtà, se qualcuno avesse qualche idea su quanto sia ragionevole avere un messaggio in coda dietro un livello dei servizi Web, sarei interessato a sentirli.

architecture web-services enterprise-architecture message-queue http-response

posta David Brower 16.04.2015 - 12:13

fonte

3 risposte

Leggi altre domande sui tag architecture web-services enterprise-architecture message-queue http-response

È buona norma mettere i metodi astratti in una classe astratta anche se i metodi sono già definiti nella sua interfaccia? Enum nelle dichiarazioni di switch java e completezza

score 6 · Answer 1

La riuscita creazione del compito per fare qualunque cosa abbia avuto successo. Ciò significa che si dovrebbe cercare nel blocco 2xx dei codici di risposta.

In questo blocco si salta in fretta come risposta corretta:

202 Accepted
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.

Potresti anche voler guardare la risposta di 201 per le situazioni in cui è stata creata la risorsa (l'attività), e vuoi solo dirlo.

201 Created
The request has been fulfilled and resulted in a new resource being created.

Questo, tuttavia, non implica la natura asincrona dell'interazione e implica invece che sia lì, da qualche parte.

score 1 · Answer 2

1

Si perde l'opportunità di segnalare errori che possono verificarsi durante l'elaborazione del messaggio. In questo modo il consumatore del tuo servizio non può mai essere sicuro se la chiamata ha avuto successo.

risposta data 16.04.2015 - 15:15

fonte

score 1 · Answer 3

Usa 200 Ok

L'impostazione che proponi è comune con un'architettura orientata ai servizi (SOA). Quando si utilizza la messaggistica asincrona di solito si ha un flusso come:

--> Request
<-- Delivery acknowledgement
<-- Process acknowledgement
--> Delivery acknowledgement

È tipico usare 200 Ok per un riconoscimento di consegna riuscito. Mi aspetto che questo sia ampiamente documentato online, anche se ho appena avuto una rapida ricerca di un riferimento e non sono riuscito a trovarne uno.

Il riconoscimento del processo è una transazione HTTP separata, nella direzione opposta, e questo ti consente di segnalare eventuali errori durante l'elaborazione.