[
Lists Home |
Date Index |
Thread Index
]
Sorry for the delay answering this. Unfortunately it requires quite a
bit of delving into REST so I needed to wait until I had time. You've
said it is a simple problem but it took you hundreds of words to
describe the problem! I'll restate the problem for those who have lost
context.
Michael Brennan wrote:
>
>...
>
> Where actions become relevant is when there is more than one way to
> interpret a subelement and you want to have a consistent, modular way to
> represent the data independently of the action that will be applied. Here's
> an example modelled after the sorts of things that we are actually doing
> (though the specific syntax is just off the top of my head and does not
> necessarily match any of our existing integrations).
>
> <UpdatePerson>
> <MatchCode>someID</MatchCode> <!-- unique identifier assigned by
> remote system for synchronization -->
> <FirstName>Roger</FirstName>
> <LastName>Costello</LastName>
> <Addresses>
> <RemoveAddress>
> <ObjectID>xxxxxx</ObjectID>
> </RemoveAddress>
> <AddAddress>
> <AddressType>home</AddressType>
> <Street>123 Main St.</Street>
> <City>Hometown</City>
> ...
> </AddAddress>
> <AddAddress>
> <AddressType>work</AddressType>
> ...
> </AddAddress>
> </UpdatePerson>
>
> The context in which we use something like this would be a situation where
> there is a fair amount of collaborative workflow between our system and a
> CRM system at a remote location. To support these collaborations, we define
> a shared information model and rich messages that allow one or the other
> system to synchronize the other systems view of the model. Typically, one
> system is designated as the master and is the only one to make changes to
> the information. The information model -- and the processing model -- is
> abstracted from what is really going on. For instance, the information model
> presented is hierarchical from the point of view of a message, though it is
> stored in a relational db. The semantics of "RemoveAddress" is not that of
> an RPC call or a simple DB insert. It simply means that the shared
> information model must reflect that that address is no longer associated
> with the parent Person entity. In our implementation, there are various ways
> something like this might be handled. Many types of records are never
> actually deleted. They just get a marker indicating they are deleted and
> they don't show up in the UI anymore. But some others do actually get
> deleted. It might not even be just one record, even though it looks like one
> in the XML message. The AddAddress is similar. If this is a containment
> relationship, this might actually add a record to the DB -- and in this
> instance, the address would have to be added after the Person to ensure
> referential integrity. If it is a many-to-many relationship (which is
> actually the way we do addresses), it might just add a link to an existing
> Address record (and likewise the RemoveAddress action might simply remove a
> link rather than delete the record). If the Person-to-Address relationship
> is a many-to-one relationship (not that you do that with people and
> addresses, but just as an example), then adding the address would happen
> *before* adding the person to ensure referential integrity. These
> interpretations of "AddAddress" and "RemoveAddress" are up to us to define,
> not the client. The client only cares what the shared information model
> looks like after a command and all of its associated subcommands are
> applied. This is not RPC, and there is no more coupling than that necessary
> to support the requirements. If an integration does not require such
> fine-grained synchronization of a shared information model, then we would
> try to adhere to one top level action. This is actually what we used to do,
> but we moved to this pattern of nested actions in order to support more
> demanding requirements from customers that we not fitting well with such a
> simplistic scheme.
>
> If someone wants to show me a useful and practical way to collapse these
> sorts of granular actions into a single top-level URI, I'm all ears. I'd be
> happy to learn such an approach, but we have real world requirements that we
> must fulfill -- and I would add that one of those requirements is to keep
> things simple for customers, most of whom don't give a damn about the W3C or
> the semantic web.
Okay, first, let's distinguish between REST and HTTP. If you think of
REST as a modeling approach (like OO modeling) then HTTP is to REST as
Java or C++ is to OO. Now when I say that REST is a modeling approach,
I'm not saying that you need to model your entire organization around
it. But you do have to accept that it is more intrusive than an RPC or
distributed objects model. Building systems that are exposed to the
outside is fundamentally different than building internal systems. You
can of course treat internal systems as a special case where security
and extensibility are not as important, but you can't treat external
systems as a special case of internal ones.
Your message above is in some ways out of sync with REST, and in some
ways out of sync with HTTP. If one accepts that the "right way" to use
HTTP is according to its REST design then of course those issues must be
solved first. It is like understanding your object model before figuring
out how to write Java code.
REST-ifying systems is first and foremost about making things
universally addressable through URIs. So your
"<MatchCode>someID</MatchCode>" would become
www.somesitecom/people/someID. Now you have standardized ways of
deleting, reading, writing and referring to people. You would give
addresses URIs too, instead of object IDs. You would use DELETE methods
to delete them, POST methods to add them, PUT methods to overwrite them.
You would associate them with people through hyperlinks (XLink or, more
likely, RDF). Note that where you had <UpdateAddress><ObjectId>...</></>
we now have
PUT addressURI
<address>
...
</address>
So protocol is separate from content. Verb is separate from noun. You
already had few verbs, which is part of REST design, but that was
obscured by the fact that you merged verb and noun into a single element
type name.
The next issue is how to install atomicity and consistency. HTTP is
optimized for the coarse-grained transactions that are typical for
partner-facing web services. (this problem is obviously not typical of
those applications) We would have to extend it (either formally, through
a new method or informally) to allow a batch submit where the server
analyzes several messages, determines the dependencies between them and
tries to do an atomic commit. This has been proposed before:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html
But for most applications this would probably fall outside the 80/20
rule. Maybe HTTP 1.2. Luckily HTTP is extensible. Many requests for
extension involve atomicity. As I said, there is already a rough
proposal for how this might look above. Another idea is to have an HTTP
method at the start and end of a set of atomic transactions. To do it in
"pure HTTP" you would create an idea of transaction resources, use a
POST to make new ones, and refer to the transaction in your PUTs and
DELETEs.
If one doesn't want to go that level of HTTP wizardry, it is only
slightly less RESTy to do this:
POST /people/personid HTTP/1.1
<DependentHTTPMethods>
<HTTPMethod action="DELETE" uri="http://.../some_address"/>
<HTTPMethod action="UPDATE" uri="http://.../some_address";
content="attachment_1"/>
...
</DependentHTTPActions>
MIME attachment 1:
<address>...</address>
This would be generally REST-ish in that it separates the action from
the content, uses URIs, uses a limited number of generic methods,
separates action from content and thus decouples them, etc.
In order for me to be confident about a solution, I'd of course need to
have a more formal description of the requirements and constraints. I'd
also need to list the various potential solutions (extension methods,
transaction resources, XML vocabulary etc.) and weigh costs and
benefits.
Paul Prescod
|
