Reputation: 1596
I am working on a RESTful api. Now I categorize requests into get, modify and action.
An example for action is OPTIONS /dogs/:id/feed
, this will result in dog status changing flowing the logic defined in server scripts.
So, will there be any problems if I use OPTIONS for this usage?
Upvotes: 2
Views: 1271
Reputation: 860
An example for action is OPTIONS /dogs/:id/feed, this will result in dog status changing flowing the logic defined in server scripts.
Why don't you use POST
in this case? Actions are just a model for something you create/update, so you can use POST
(or PUT
in the case you know where to put the resource).
In this case, I would do the something like:
POST /dogs/:id/bowls
Content-Type: application/json
{
"bowlContent" : <food description>
}
This will create a bowl with the food inside (the meaning of feed in fact).
OPTIONS
is often used to query how you can use a particular resource (meaning what are my options? See http://zacstewart.com/2012/04/14/http-options-method.html), or as preflight requests in cross-domain Ajax calls (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS). You should not use it for any other purpose.
Upvotes: 1
Reputation: 42025
There might be problems, because you're abusing OPTIONS. Read Section 4.2.1 of RFC 7231 (https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.2.1):
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
...
Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.
Upvotes: 4