JJ, consider AtomPub and we draw a UML class diagram to represent its resource models (e.g. Service Document, Collection, Entry, Media Resource) as classes, then try to draw association links between them and label the links.
E.g. a Collection contains 0 or more Entries.
Collection -----> [0..*] Entry
How would you label this association link? I would label it as: atom:entry/atom:link[@rel='edit']/@href
E.g.2 a ServiceDoc describes 0 or more Collections.
ServiceDoc -----> [0..*] Collection
I would label this as: app:collection/@href
> How are the semantics of returning a single resource versus a collection of resources defined?
As in AtomPub, each resource model is mainly defined by the association link pointing from another resource model.
Consider an OpenSearch document, it also has a link (template) that defines a set of resources as resultsets: opensearch:Url/@template
Teo:
thanks for your comment. I am not discussing the fact that I can address a collection by a URI which includes a query string (in whatever format it is expressed - you could use an Xpath expression as you suggest (if I understand your point correctly).
I am really talking about the difference between a result set and a collection. Sure, I understand that I can represent a result set with a collection. But now that I got this result set as a collection (the reasoning using an openSearch document would be the same), what does a PUT means? This collection is artificial (not even virtual). When I add something to a resultset, what are the semantics of this add? which collection am I updating? Yes, the entry belongs to a collection, but I may not have returned the link to that connection to update it. in APP, you are clearly dealing with collections of entries, so there is no ambiguity there.
So I would like to stand by my argument that a result set defined by a Query URI is not a resource.
On the "one entry result set" question, I think you clarified, if I use APP, there is no ambiguity. So definitely APP is adding value to REST, but I am not sure it is resolving the question "resultset" versus "collection". The service responsible for processing the update on a result set (if you are familiar with SDO, you know what I am talking about) has to have the knowledge of both the semantics of the resultset as a representation and the resource and how they relate to each other. You cannot achieve this generically.
JJ-
> I am really talking about the difference between a result set and a collection.
I find myself using a resource model as an abstract interface. E.g. AtomPub's Collection is an interface that defines the meaning of GET and POST. We know a resource implements AtomPub's Collection interface when its URI appears in app:collection/@href.
OTOH, OpenSearch's ResultSet is a separate interface that defines the meaning of GET. We know a resource implements ResultSet interface when its URI can be constructed from: opensearch:Url/@template
As in APP, a service provider publishes hyper-linked documents with embedded authoritative declarations on which resources implement what interfaces. A client agent receives these declarations at runtime as it needs them, when parsing and crawling through the published documents.
>> We know a resource implements AtomPub's Collection interface when its URI appears in app:collection/@href.
let's take an example. Say I run a query that gives me all the purchase orders that contains product where productID = 123.
I agree with you that APP adds valuable semantics that were missing in HTTP, but APP does not have the semantics of resource associations. What does it mean to add a purchase order to this collection? it is meaningless, right? Neither APP nor HTTP give you the "root" where the order belongs. So if I want to add a purchase order to that collection how do I do it? How do I navigate back to the customer from there? You are going to tell me a user sees the customer, clicks on it, and then there is probably be and "Add Order" link somewhere that the user is going to make sense. My question is how all this works when a user is not there, and this is a service consumer which has to do the same thing?
My understanding is that neither APP or OpenSearch (though OpenSearch has a better shot at it) really defines the semantics of resource association.
See the problem I have is not with REST/HTTP or with APP or OpenSearch. All are perfectly valid technologies. The problem I have is that the RESTifarians make a ton of assumptions that are baked in the code (actions, association, message reliability, transactions,...). Apparently APP is becoming REST's SOAP. Again I have no real problem with people re-inventing the wheel, I take issue with people telling me I don't need any of what I have and then the next thing they do, they serve me something different that amounts to what I had.
> but APP does not have the semantics of resource associations
I think most will agree that APP has standardized a few general association semantics (e.g. Collection-Entry, MediaLinkEntry-MediaResource). But nothing prevents a domain group to standardize a set of domain-specific association semantics through hooks in Atom 1.0 e.g. atom:link, atom:category.
> How do I navigate back to the customer from there?
If we can program an automated client to recognize atom:link[@rel='edit']/@href as a URI reference of an Atom Entry, we can also program it to recognize atom:link[@rel='http://../Customer']/@href as a URI reference of a Customer Resource. Agree?
>> But nothing prevents a domain group to standardize a set of domain-specific association semantics through hooks in Atom 1.0 e.g. atom:link, atom:category.
Yes, that’s the problem I have with you guys, all this has already been invented, you are taking super simple use cases and applying super simple solutions to it. This is fine, but don’t come back and give us lessons about what is an action, a trans-action, an association, robust message exchange… Smart people have solved these problems before you through painstaking work. All you are telling us is “start over”, for what benefit?
>> [@rel='http://../Customer']/@href
again, my issue is that you are giving me something that works in a simple example. In this case, orders are naturally added to a single collection: customer. Sure, a lot of information looks hierarchical (when you create a picture that is small enough), but information is relational in nature, there is nothing you can do about it. When I have a choice to add a piece of information to two or more possible relationships, how can I express this in APP? More importantly, how can an automated client decide where to add a piece of information without shared understanding of the meaning of one relation versus the other?
In essence what you are trying to argue is that: APP + HTTP = SQL + WSDL + SOAP. I am sorry, but it does not add up. I appreciate the merits of APP + HTTP to solve elegantly quite a few things, but that does not make it something general.
I will create the Metamodel of APP to better be able to discuss these points.
JJ, the HTTP uniform interface explicitly allows for methods to be "not allowed" on certain resources -- e.g. a PUT on a search result would simply be not possible (even for a generic client, and the result would indicate the reason).
The main indicator that something is a resource is that I can link to it. I can link to search results and stock quotes just fine.
Caching stock quotes that are updated every 15 minutes with a reasonable expiry time seems perfectly valid to me, too.
Ok, sounds good then, we resolve that question. This is a bit loose for an IS-A relationship (you pick what's allowed) but if it is allowed, it is within the semantics of REST.
This question is closed from my perspective.
thanks,
JJ-
Commenting by HaloScan
