views:

427

answers:

3

Our whole system is being designed around REST and are now considering how processes which are quite clearly RPC in intent can be mapped to RESTful resources without using verbs in the URL. Our remote procedure call is used to rebuild our search index when a content listing has been modified elsewhere.

What we are thinking about doing is this:

POST /index_updates

<indexUpdate><contentId>123</contentId></indexUpdate>

Nothing wrong with that in itself, but the smell is this resource which has been created does not return the URL of the newly created resource e.g. /index_updates/1234 which we can then access with a GET.

The indexing engine we are using does have a log mechanism, so in theory we could return a URL to a index_update resource so as to allow a GET to retrieve the resource, but to be honest we're not interested in the resource as this is nothing more than an RPC in disguise.

So my question is whether RESTfulness is expressed in structure or intent. I feel the structure of what I have outlined is restful, but the intent is not.

Does anyone have an comments or advice?

Thanks,

Chris

+4  A: 

Use the right tool for the job. In this case, it definitely seems like the right tool is a pure remote procedure call, and there's no reason to pretend it's REST.

Matthew Flaschen
Agreed, but REST is new to our office and the transition in thinking from actions to resources is proving difficult. I wanted to avoid allowing RPC over HTTP into the mix at the moment, as it might open the door to developers falling back to RPC which comes easier to them.
ChrisInCambo
In my opinion, the solution is to use this as an opportunity, not a "slippery slope". Explain why this is an appropriate situation for RPC, and why your general architecture uses REST. There is no conflict.
Matthew Flaschen
Yep that's also what I'm thinking now, I don't think we need the complexity of soap, but just simple RPC calls over HTTP, and clearly explain to everyone why an RPC as been used in this case rather than running away from or trying to hide the fact. Good call.
ChrisInCambo
A: 

This is obviously a subjective field, but GET PUT POST DELETE is a rich enough vocabulary to describe anything. And when I go to non-English-speaking Asian countries I just point and they know what I mean since I don't speak the language... but it's hard to really get into a nice conversation with someone...

It's not a bad idea to disguise RPC as REST, since that's the whole exercise. Personally, I think SOAP has been bashed and hated while in fact it has many strengths (and with HTTP compression, HTTP/SSL, and cookies, many more strengths)... and your app is really exposing methods for the client to call. Why would you want to translate that to REST? I've never been convinced. SOAP lets you use a language that we know and love, that of the programming interface.

But to answer your question, is it a bad idea to disguise RPC as REST? No. Disguising RPC as REST and translating to the four basic operations is what the thing is about. Whether you think that's cool or not is a different story.

Yar
Thanks, I'm based in SE Asia, so smiled when you mentioned the ease of explaining the REST verbs. I'm not completely against soap and would probably consider it if the RPC's in question weren't so trivial.
ChrisInCambo
That's the point about SOAP: regardless of your programming language, it's ALWAYS easier than REST because there are APIs for it. Whatever your language, you can probably just mark a class as SOAPy and it will automatically get a WSDL, etc. So trivial is non-trivial.
Yar
REST is more then just HTTP verbs. Also, I am not sure that SIAP is always easier then rest. When you can do SOAP easily with wget, then I'll consider that idea.
Jonathan Arkell
Why? For debugging? Or do you actually use wget as part of your app? Whatever you need to figure out SOAP is already built since it's been around for a while.
Yar
+2  A: 

One reason you might return a new resource identifier from your POST /index_updates call is to monitor the status of the operation.

POST /index_updates
<contentId>123</contentId>

201 Created
Location: /index_updates/a9283b734e

GET /index_jobs/a9283b734e

 <index_update><percent_complete>89</percent_complete></index_update>
Mark Renouf
Good idea, it is a length operation so having status details would be useful.
ChrisInCambo
+1 IMO a POST doesn't have to return a new location if you don't wish to expose any verbs on the new resource. And|Or even returning a 405 on /index_updates/123 for all verbs could be a solution??
Martijn Laarman