CODEWITHSUNDEEP
restoperations
Jeff Wang
Jeff Wang

Reputation: 1867

RESTful operations, server-side operations

Ok, I've got a Payment system. Let's ignore everything around it, and focus on the Payment itself.

Through a bunch of wizards, I build up a particular payment.

First, I do a

POST /payment

server returns

LOCATION /payment/{id}

first Wizard page:

PUT /payment/{id}

server returns

201 (Created)

Subsequent wizard page:

PUT /payment/{id} and POST /payment/{id}/{subresource}

server returns

202 (accepted) for the PUTs and 201 (Created) for the subresources

Last page (has nothing but a summary and an "are you sure")

Here's my question, what should I use as the REST endpoint?

PUT /payment/{id}/process

is plainly wrong, because process is a verb, not a resource.

PUT /payment/{id}

implies the client is going to do the processing, which is something the server does not trust.

PUT /payment/{id}

with the status changed (to something like "To Process") and having that status change be intercepted seems very hacky and not good design at all.

Anyone have other ideas?

Upvotes: 2

Views: 296

Answers (1)

stand
stand

Reputation: 3142

First do a GET of the payment:

GET /payment/{id}

Take that representation and POST it to a processing resource

POST /payment/processqueue

The Location header can contain a link to some resource that shows the status of the processing.

Upvotes: 2

Related Questions