3

Hi I have a Order this order needs to be sent to an order system. There are several oprations that can be performed.

  1. Create
  2. Modify
  3. Check-Modification (this happens on existing order)
  4. Simulate Create without creating it
  5. Delete
  6. get order

The way I have modeled the resource is the following:

1. PUT /orders/{id}  - CREATE operation

2. PUT /orders/{id}  - if exists MODIFY

3. POST /orders     - no ID is specified so simulate is executed instead .

4. POST /orders/{id}  - id is specified it performs modification check without persisting it.

5. DELETE /orders/{id}

6. GET /orders/{id}

Now my question is about number 3 and number 4.

How do you model actions on resources. Is my mapping good or I should have mapped the actuon via url the following way:

/orders/id/validate
/orders/id/simulate

what is more correct with regards of REST ?

What if we use 3 and 4 and then more actions come at later point? What we create operation field and place the operations under ? Or should the operations go in the url ?

Is it ok to use PUT on /orders/id/validate if I don't want the key to be created at all but just validated? Should it be post instead ?

2
  • I cannot over recommend Richardson's and Ruby's RESTful Web Services. It will guide you through understanding to model nouns rather than actions and how to use the native HTTP verbs ("actions") on those nouns. Dec 19, 2019 at 14:24
  • Why the downvote ? Dec 19, 2019 at 14:49

4 Answers 4

2

REST doesn't really care about what URIs you choose. Normally, you would supply those URIs to the client anyway in the responses you provide, so you are free to change them anytime you want on the server.

Now, if you hardcode URIs into the client you might have an issue changing them later, but even then, you can come up with any new URIs to cover new functionality.

So to sum up: Yes, those URIs are fine, as long as the semantics of the methods (GET, PUT, POST) are adhered to.

On that note, for your validate functionality you should use POST, as PUT is assumed to create a resource on the server per its semantics.

1
  • There are two dets Of ids, which one FoU you mean? The one that has the action in the URL, or the other? Dec 19, 2019 at 14:10
2

We had a similar situation at work,the intention was to simulate a user request called as Dry Run in our terms. This was to see whether the system had sufficient data which could fulfill the request. Because we had loads of business requirements, while a process went on.

I only have one comment in terms of the creation and the simulation.

  1. Let the creation use post as creation: POST items/{requestObject}

  2. In your request object, define a boolean field simulation/dryRun, and still send the request to the above endpoint

1
  • Even better, split the responsibilities and introduce a boolean request parameter to the POST endpoint and specify the run mode there. This fixes a potential issue where you would e.g. need to have a test as an attribute on the object, as well as test as a boolean to indicate whether the operation should actually go through, or not.
    – Andy
    Dec 20, 2019 at 7:19
1

what is more correct with regards of REST ?

REST only says that resources shall have a uniform interface; GET/PUT/POST and so on come from HTTP.

A "non-persistent action" sounds like you want the semantics of the request to be safe. Core HTTP doesn't define any methods with safe semantics that also defines semantics for the message-body. A review of the HTTP method registry suggests looking into SEARCH and REPORT, but those come from WebDAV, so the defined semantics may not be as general as we would like.

Fielding, writing in 2009

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

What follows is all rooted in the assumption that this VALIDATE/SIMULATE isn't worth standardizing.

A reason that we care about which URI is used in the request is caching, and cache invalidation. A successful POST to /x invalidates the cached representations of that resource. This is exactly what we want when we are changing the representation of /x -- for example, when adding a new item to a collection, the stale representations of the collection itself are what we want to invalidate.

In this case, where we are using POST for something safe, the "cache invalidation" rules are not in our favor, so we may want to use a different target uri so that something meaningless is invalidated instead.

Based on this, I think you can argue that using different URI for the not-persisted actions is more "RESTful" than using the same URI.

Neither REST nor HTTP offer any useful suggestions on the spellings of the URI to use; as long as they are consistent with the production rules defined in RFC 3986, the machines don't care.

In REST applications, like the world wide web, the human beings don't really care either -- when was the last time you looked to see what resource was handling your google search? or your stack overflow answer submission?

But, just as with variable names, we try to design URI that make things easy for the human beings who do care.

/orders/id/we-use-this-resource-for-something-weird
0

REST is very loose and can mean different things to different people. My choices would be

POST adds a new item to a collection. Hence you can only

POST /items

NOT

POST /items/100

PUT (over)writes an item to an existing location, hence you can only

PUT /items/100

PUT requires all fields of an item to be present. When only a part of an item is being modified, use

PATCH /items/100

When a behaviour change is requested, use query parameters, i.e.

POST /items?whatIf=true

(to address your simulate operation)

When an operation clearly doesn't fit into one of the HTTP verbs, I prefer to POST a command object. For example:

POST /orders/100/additem

Do be mindful to adhere to REST's statelessness requirement. I would not POST an order and then validate it in another call. And in the meantime it's in an in-between state waiting to be validated. if that was to happen I'd have the semantics represent that, like a POST /cart etc.

1
  • Put can also insekt new item. IT is not nesseserily overwriting one. This is specificaly true when the ID Of the item is supplied from outside. Dec 19, 2019 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.