Ad hoc protocol vs adopting APP, Google Data or another existing (and well known) protocol - advice needed.
mark Kharitonov
I intend to port our client-server to the REST technology. There are many questions, one of which is the high level protocol exposed by the server. Our server basically supports the following types of actions:
- CRUD
- Synchronous commands - the command result is ready immediately and is returned in the response.
- Asynchronous commands - the command triggers some action, which takes time (potentially days) and it is the client's responsibility to continuously poll the server until the command action is completed.
Can anyone advice based on his/her experience with similar systems? APP sounds exactly like CRUD, but then I may be missing something. Besides, how do commands (synchronous and asynchronous) fit into this model?
Or may be I should adopt Google Data (which is an extension of APP, if I get it correctly) ?
Or something else entirely...
Thanks.
mark Kharitonov
Sebastien Lambla
Sorry for the delay in answering, it’s been a very busy couple of weeks.
The advice I give to students that come to my course is that you should adopt a media-type if and only if the content model in that media type matches what you’re trying to do. If you want simple file access, HTTP is enough as it already has all the semantics necessary for managing files, minus collections. That you can get by implementing a subset of webdav for example.
Alternatively, collection of files may map well to Atom feeds, provided you have all the metadata needed for the feed to be useful to any atom feed reader and not just your own. It’s the genericity of processing rule, reuse a generic type and advertise yourself as it if and only if someone can do useful stuff without knowing anything about your extensions or how you provide them.
GData or OData suffer a lot from not respecting that genericity rule, and make those media types difficult to handle and create without reusing the code that the two vendors responsible for those techs provide.
As for CRUD, HTTP is not designed for CRUD, it has different semantics: identification of the subject of an operation is not in the body, it’s the resource uri, and while POST *can* be used for the Create (and many other things), PUT means “Save at the URI”, which may be a create or an update / overwrite.
In general I tend to try and model things by reusing as much as I can of the standard stacks and limit my custom extensions to where they are absolutely needed, and if I do need a custom media type (which you would always need for json, as it hasn’t got any content model to speak of), then I always mint a fresh Media Type Identifier.
From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of mark Kharitonov
Sent: 26 June 2011 20:52
To: open...@googlegroups.com
Subject: [openrasta] Ad hoc protocol vs adopting APP, Google Data or another existing (and well known) protocol - advice needed.
Dear ladies and sirs.
I intend to port our client-server to the REST technology. There are many questions, one of which is the high level protocol exposed by the server. Our server basically supports the following types of actions:
1. CRUD
2. Synchronous commands - the command result is ready immediately and is returned in the response.
3. Asynchronous commands - the command triggers some action, which takes time (potentially days) and it is the client's responsibility to continuously poll the server until the command action is completed.
mark Kharitonov
--
Be well and prosper.
==============================
"There are two kinds of people.Those whose guns are loaded and those who dig."
("The good, the bad and the ugly")
So let us drink for our guns always be loaded.