CODEWITHSUNDEEP
rest
konkov.alex
konkov.alex

Reputation: 101

REST services design: cancel an order?

Given order cancelling as a requirement, what is the best design option of representing this operation in RESTful way and why?

I can think at least of the following

Upvotes: 7

Views: 4674

Answers (3)

Fernando Silva
Fernando Silva

Reputation: 1

One option is using patch: patch /api/resource {cancelled:true}

Use patch for partial updates.

Upvotes: 0

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57397

Given order cancelling as a requirement, what is the best design option of representing this operation in RESTful way and why?

Think about how you would cancel an order on an website....

You would GET the order; within the representation of that order would be a link, with some semantic markup like to cancel your order, click here. Following that link would bring you to a cancellation form, with controls representing the information that needs to be submitted, probably with default values provided. You would then submit that form, and the response back would communicate the status of your attempt to cancel the order.

The right RESTful approach is to do that. The key idea being that the representations provided by the server tell the client how to do; the client only needs to have advanced understanding of the protocol: what links to look for, what form semantics to look for.

(In short, what REST tells you to do is build a website for your integration domain, with machine readable representations of the application states.)

The why is that it allows the provider and the consumer to evolve independently; as long as the protocol between the two remains stable, you can change the underlying implementation of either as often as you like.

Upvotes: 0

Artem
Artem

Reputation: 2314

Take in mind that your resource should be a noun, not a verb or an adjective. Your http is responsible for telling what you are doing with the resource

  1. /orders/{id}/cancelation

PUT - cancels order

DELETE - rolls back cancelation (might be a scenario as well)

GET - returns cancelation details (you may want to extend cancelation resource with timestamp and username fields for example)

  1. /orders/{id}

PUT (PATCH) - it is okay to cancel by passing something like:

{
    ...
    "order_status": "CANCELLED"
    ...
}

It really depends on your business domain, but the first one sounds preferable for me because it adds some flexibility like extending model with timestamp and cancelation of cancelation.

Upvotes: 10

Related Questions