Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00

[Jan Algermissen <[e-mail]>]

On Apr 10, 2012, at 5:56 PM, Mark Nottingham wrote:

> > one example i am currently considering adding is atompub. currently, when you retrieve a feed, there's no way to tell it's atompub-capable just by looking at it.

The thing is that it is not necessary to *learn* this. If it is your expectation that the service you are interacting with is actually an atompub service then fine, go ahead. If the service behaves as you expect, fine; your use case succeeds.

If it isn't you'll discover that from the response and change configuration of your set of entry URIs or whatever.

The decision regarding your use case comes first and you do not need to double check at runtime. For example, you have a bookmark for your favorite search engine. Do you check every time you use that bookmark whether the search engine is still there? Or do you just use the bookmark based according to your expectations?

Likewise, what does that check for atompub capabilities buy you? The reason you check for them is that you assume they are there in the first place. If that check fails .... then what? You are in exactly the same situation as when you POST you atom entry right away and see what happens.


The nature (as in "Amazon is an online store") of services changes slowly (if at all) and the particular HTTP idioms that services use also changes slowly (e.g. creation with PUT vs. creation with POST). In REST there is, IMHO at least, a third xxx-time besides the traditional design-time and run-time. It is what I think of as 'configuration-time'. This is where a method like OPTIONS plays its part, for example. Try out a service once, learn what it is and what its particularities are and then adjust your configuration for interactions with that service. The things you discover at configuration-time are not likely to change soon. If they do, you adjust your configuration and maybe you do not need to do that , ever.

> 
> Well, what thing in this case is atom pub capable? The format that the links are occurring within, or the targets of the links themselves? I'd argue the latter. You can take that argument too far, of course, but generally I see profiles as describing format conventions, and link relations as describing behaviours of resources. Of course, some of those behaviours can be "produce this format" and some of the formatting conventions can be "link to something with this behaviour".
> 
> Am happy to be proven wrong on this, I just think we need good patterns of use / best practices to encourage reasonable design.

+1

Jan


> 
> Make sense?