On 25/02/11 20:31, Leo Romanoff wrote:
> To some extent, our current RESTful API follows this
> idea. We use the patterns like:
>
> POST /service/startProcess -> would return the process id of newly started
> process
> GET /service/process_id/state_resource_path
> DELETE /service/process_id
>
> But as I mentioned, this process has a LOT OF state. Replicating its state
> between cluster nodes is very difficult and inefficient for different
> reasons. Therefore, only the cluster node owning the process can process
> requests related to it. And I do not see yet how your proposal helps in this
> regard. Or may be I misunderstand what you say?
It seems to me that the point of a "cluster" is usually to hide the
existence of multiple server nodes from the client. But in your case,
this is precisely what you DON'T want to do. You actually want the
client apps to deal with a particular server in the cluster.
In the scenario you gave above, your client asks the server to create a
resource representing a "Process", and the server responds with the URI
of the process. That URI should specify the concrete server in which the
process runs, e.g.
POST
http://myserver.example.com/service/startProcess -> returns the URI
http://myserver7.example.com/service/process22
Then your client can interact with the service running on myserver7;
monitor it, and delete it from there.
--
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297