RESTful way to send commands

Question

How do you send "commands" to a RESTful server?

Use case. My server caches certain information so that it cannot read the database every time this information is requested. I need a way to send a command from my client application to tell the server to flush the cache. Would you use POST or PUT at some url like "... / flush_cache"?

A “command” is not data for which a “Transmission of view state” is required, unless the transferred state is the result of a command - “off”, “cache cleared”, etc. Typically, how does REST send commands to the server?

Answer 1

I faced this situation a lot in the last project. Since REST is good ... about a resource, it is not always clear how to deal with things that are truly RPC in nature.

An easy way to get around this is to think of it as a bureaucratic part of peace; the request may be the resource itself:

1. "Do you want to call the command on my server? First, fill out this form I90292 and send it to us":

POST /bureaucracy/command-request Content-Type: application/x-www-form-urlencoded Content-Length: ... 

2. "Well, we'll see what we can do. Your case number is 999."

   201 Created (or 202 adopted in accordance with Kugel’s comment) Location / bureaucracy / request team / 999

3. And then the client regularly checks

   GET / bureaucracy / command-request / 999

I hope he gets an answer like the following

 200 OK <command-request> <number>999</number> ... <result>Success</result> </command-request> 

Of course, if the bureaucratic service will have great customer care, he will offer the client to call him when this is done, if he wants:
"Do you want to run the command on our server? Please fill out this form and send it to us. Please note that you can join your contact information so that we can call you when this is done."

 POST /bureaucracy/command-request?callback=client.com/bureaucracy/inbox 

Or as a custom X-Callback: http://client.com/bureaucracy/inbox http header X-Callback: http://client.com/bureaucracy/inbox

Answer 2

I would suggest the following:

• Create a resource that you can GET that tells the client how to send a command that looks like an HTML form using POST if there are side effects to this command.
• POST for the resource to run the command and return the URI to the new resource that you create during the execution of this POST request (for example, http://server.example/results/00001 ), possibly with a status of 204 (without content) and a location header or redirection (depending on which client can understand).
• Let the client verify the results on this resource using GET. You can also return the view for this resource (or something similar) as the object returned by POST before that.

It is up to you to determine the life cycle of the result resource. This can be short-lived if you do not need to store the results for a long time. A URI may be constructed, for example, from a UUID.

Answer 3

In your case, why not make a cache resource?

 DELETE /cache 

If you want to clean it.

 POST /cache 

when you want to create a new one.

Or combine the previous two into the following:

 DELETE /cache?autorecreate=true