Paul Prescod wrote:
> Philip Eskelin wrote:
> >
> >...
> >
> > I'm not sure where my version of this verb/URI issue stands, but
> > here is the way I have designed it in my own efforts. As I mentioned
> > before, I have a pre-developed set of resource types, namely methods,
> > components, topics, queues, etc that are published in a node's
> > hierarchical namespace.
>
> I guess the basic question is whether you *need* method objects. A
> REST-purist view would be that you should use methods as an
> implementation technique to implement a resource view of the world.
> Since I don't know what method objects you have, I can't
> resource-decompose them. But in most cases you will want an action to
> have a side-effect that creates a resource+URI, and you will want the
> newly created resource to be in some container. So you can
> instead use a POST on the container.

My question was "what are you posting to?" and that's where I came up with the
idea of creating method resources, which have URIs (if they are published), can
be invoked via POST, and need to exist in a container. GETing, PUTing, and
DELETEing methods act on the resource itself.

> >...
> > HTTP PUT - instead of getting a pre-existing resource like the one
> > above, it allows you to effectively copy a resource in its current
> > state to another node. You are effectively publishing it on the
> > destination node.
>
> It's not clear to me how you can copy a method. After all, the real
> method is the programming code behind it. And that code will
> depend on a complex network of other state. So PUT-ting to a method
> resource doesn't make much sense to me.

Sorry about that - I'll clarify. One thing I forgot to write into my original
method example was a "localHost" property that references the component where
the implementation of the method is hosted. So if you merely copy the method
resource, it then exists in a new container but references the same
implementation.

So if you wanted to do what you thought I meant in your response, you would also
need to copy the component to a new location, update new method's localHost URI,
and integrate the new component into its environment. If the destination node
was identical to the source (code doesn't always depend on a complex network of
state), then it might work without modification.

I agree with you, PUTing to a method resource doesn't make sense. Instead, you
would want to PUT the method to a container. Is that more clear? Like Roger, I
want to make sure my work reflects resolve on these issues.

-Philip