Rest API Design in caso di parziale successo

I codici di ritorno HTTP sono progettati per gestire il protocollo HTTP, non tutte le possibili richieste / risposte.

Piuttosto che selezionare un codice oscuro che può, forse, essere interpretato, grosso modo, come quello che vuoi, se lo stai strizzando. È sufficiente restituire più informazioni nel corpo della risposta

200 OK
{
    "userCreation" : "Passed",
    "ticketReservation" : "Passed",
    "paymentProcessing" : "Failed"
    "orderStatus" : "PendingPayment"
}

Restituire una risposta 202 Accepted è una buona idea qui.

Da Wikipedia :

The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.

Questo stato è riservato a casi come questo in cui le cose stanno andando bene in questo momento, ma alcune elaborazioni fuori banda sono in corso e il client dovrebbe controllare più tardi.

Possono verificarsi tutti i tipi di elaborazione "fuori banda". Come l'ottimizzazione di immagini o video dopo averli caricati, o, come nel tuo caso, l'elaborazione di un pagamento con carta di credito.

Potresti introdurre un altro oggetto nel tuo sistema, una richiesta di acquisto del biglietto.

Quando l'utente tenta di acquistare un ticket, si crea immediatamente uno di questi oggetti (e un ritorno dalla creazione di un ID corrispondente).

Quindi il chiamante può monitorare lo stato di questa richiesta, con chiamate a GET / ticket-purchase-request / {ID} utilizzando l'ID restituito in precedenza. Può leggere di nuovo lo stato che è ancora convalidato dalla società emittente della carta di credito, o che è fallito.

Non sono sicuro del motivo per cui vorresti ritentare automaticamente la richiesta della carta di credito? Se ha fallito, e stai dicendo che è a causa di richieste fraudolente, non vedo alcun motivo per riprovare. L'unica ragione per riprovare sarebbe se un errore transitorio (connessione di rete o server occupato, ad esempio) ha causato il fallimento della carta di credito. Devi controllare il codice di stato restituito dalla società emittente della carta di credito (se dicono rifiutato non riprovare).

I have a solution in mind, I will not proceed with issuing ticket in payment fail , instead I want to return something different http code to client. like everything else except payment is success.

In caso di dubbi, pensa a come funziona nel tuo browser web.

La maggior parte delle volte, noi, i consumatori di un sito Web, non prestiamo alcuna attenzione al codice di stato che viene restituito dal server. Quello che guardiamo è il payload.

Il pubblico per lo status-code? I componenti generici (browser, proxy, cache) che utilizzano i metadati forniti per supportare le capacità generalizzate.

Jim Webber l'ha detto in questo modo

The web is not your domain, it's a document management system. All the HTTP verbs apply to the document management domain.

Lo stesso vale per i codici di stato. Si tratta di metadati relativi ai documenti, con semantica standardizzata che consente ai componenti generici di fare cose intelligenti: aprire una finestra di dialogo di accesso perché è necessaria l'autenticazione, invalidando automaticamente le rappresentazioni memorizzate nella cache, invalidando i segnalibri ....

Quindi Ewan ha l'idea giusta: inserisci le informazioni di cui il consumatore ha bisogno nel documento. Definire il tipo di supporto e lo schema in modo da poter coprire i casi d'uso necessari. Quando rispondi a una richiesta, calcola il documento corretto da inviare per primo, quindi considera quali informazioni devono essere sollevate nei metadati.

Questo non è un trucco per aggirare un caso d'uso insolito - questo è il modo in cui le API HTTP dovrebbero funzionare sempre.