Rest API Design in case of partial success

Question

So I have a ticket booking system.

I have ticket booking request on api, from my application we call payment service.

If failed on first attempt we proceed by adding message on queue for handling payment later. And proceed with issuing ticket to customer.

From queue we retry payment with payment api 10 times in 10 minutes if no success we add some status to that ticket booking record and by offline mean get money from customer.

Problem: We are getting many such booking due to credit card frauds.

Solution:

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.

And while processing message from queue if it fails after 10 attempts I want to inform client this transaction is failed.

If pass let client know to proceed with issuing ticket

Question: Does this solution have technical feasibility ?

Answer 1

The HTTP return codes are designed to deal with the HTTP protocol, not every possible Request/Response.

Rather than selecting an obscure code that can, maybe, be interpreted, roughly, as what you want it to, if you squint at it. Simply return more information in the response body

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

Answer 2

Returning a 202 Accepted response is a good fit here.

From 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.

This status is reserved for cases like this where things are going fine right now, but some out of band processing is going on and the client should check back later.

All kinds of "out of band" processing can occur. Like optimizing images or video after uploading them, or, as in your case, processing a credit card payment.

Answer 3

You could introduce another object in your system, a ticket-purchase-request.

When the user tries to buy a ticket, you immediately create one of these objects (and a return from the create a cooresponding ID).

Then the caller can monitor the status of the this request, with calls to GET /ticket-purchase-request/{ID} using the ID returned before. He can read back in teh status that its still being validated by the credit card company, or that its failed.

I'm NOT sure why you would ever want to automatically retry the credit card request? If it failed, and you are saying that's because of fraudulent requests, I see no reason to try again. The only reason to retry would be if a transient error (network connection or server busy for example) caused the credit card running to fail. You need to look at the status code returned by the credit card company (if they say declined dont retry).

Answer 4

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.

When in doubt, think about how it works in your web browser.

Most of the time, we -- the consumers of a web site -- don't pay any attention at all to the status-code that is returned by the server. What we look at is the payload.

The audience for the status-code? The generic components (browsers, proxies, caches) that use the meta data provided to support generalized capabilities.

Jim Webber said it this way

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

The same is true of the status codes. They are meta data about the documents, with standardized semantics that allow generic components to do clever things: throwing up a login dialog because authentication is required, automatically invalidating cached representations, invalidating bookmarks....

So Ewan has the right idea: you put the information the consumer needs into the document. Define the media-type and schema in such a way that you can cover the necessary use cases. When replying to a request, compute the correct document to send first, then consider what information should be lifted into the meta data.

This isn't some trick pattern to work around an unusual use case -- this is the way HTTP APIs are supposed to work all the time.