CODEWITHSUNDEEP
rest
JavaDeveloper
JavaDeveloper

Reputation: 5660

How to model REST URL for which there is no equivalent HTTP method?

I have customers and I want to activate and cancel their plans. I am trying to be as RESTful as possible.

Should the action to perform 'active' or 'suspend' be part of URI ?

1) POST customers/{customerId}/activatePlan/{planName} 2) POST customers/{customerId}/suspendPlan/{planName}

My problem is that both activate and cancel are verbs or actions. They do not have any equivalent HTTP action ( GET, POST, PATCH etc.)

Are my URL's restful ? if not, how to make them REST ful.

Upvotes: 0

Views: 57

Answers (2)

Kasper
Kasper

Reputation: 690

Everything is a resource on the RESTful paradigm and these resources are manipulated with one of the HTTP methods (GET, POST, PUT, DELETE, etc ...).

You can create a plan with POST:

POST customers/{customerId}/{planName}

once a plan is created we have to activate or deactivate it and here we have a couple of choices:

  1. Using the action in the URI. We use PUT in this case as the planName resource exists (so it is an update):

PUT customers/{customerId}/{planName}/activate

  1. Set a property on the planName resource (still a PUT as it is an update on the planName resource). The activate property in the body of the HTTP PUT request (i.e.: activate=true or activate=false):

PUT customers/{customerId}/{planName}

then you can use GET to return the status of the planName resource

GET customers/{customerId}/{planName}

and DELETE if you want to remove planName from a customer:

GET customers/{customerId}/{planName}

Upvotes: 2

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57279

Are my URL's restful ?

All URI are RESTful -- REST doesn't care what spelling conventions you use for your resource identifiers.

Notice, please, that both of the following URI work exactly as you would expect them to:

My problem is that both activate and cancel are verbs or actions. They do not have any equivalent HTTP action ( GET, POST, PATCH etc.)

There are a couple of different answers. Perhaps the easiest is to think about how you would design a web site that allowed you to activate and cancel plans. You would probably have a web page for this customers enrollment, and on that page might be a link with some hint, like "cancel". Clicking the link would load a new web page, with a form on it, including a bunch of fields for the customer to fill in. When the customer submits the form, the browser looks at the form, and its meta data, and figures out what request to send to the server.

A "REST API" isn't about putting your domain model on the web - it's about putting your interaction model on the web. We create a collection of documents (resources) that describe the domain, and we get useful work done by moving those documents around the network. See Jim Webber 2011.

Because we are working in the language of documents, REST interfaces are usually based on one of the following ideas

  • Here is a document; make local edits to your copy of the document, and send it back to the server (GET, PUT, PATCH, DELETE are the primary method tokens you see in this style)
  • Here is a form; fill in the details and submit it (GET and POST are the method tokens you see in these cases)

If you are unhappy with the use of POST, it may help to review Fielding 2009

POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”

Upvotes: 0

Related Questions