Re: Issue-80: Post media types usable for Create; background for proposal

hello john.

On 2013-06-11 4:53 , "John Arwe" <johnarwe@us.ibm.com> wrote:

>> >"hints" are of dubious value to implementations.  If you act like you
>> you may have some misunderstanding here. hints are just optimizations.
>>for
>I think it's just a matter of where you're standing.  If you're writing
>code, you're in one of the cases I articulated.  That's the sense in
>which I meant they're of dubious value - they don't save the implementer
>from *writing* any code,
> unless the hint is taken as a trusted assertion.  It's still possible to
>avoid *running* that code, or short-circuiting some actions, and come out
>a net winner.  

link hints don't try to save you as the application programmer from
writing code. actually, it often will be the opposite: if you choose to
use them (and you're free to ignore them if you don't like them) then
you'll end *writing more code*, but your service experience will be
better. that's the trade-off.

take HTML's img/@src links. the assumption of these links is that you'll
GET some kind of image/* representation. if there was a "formats" hint on
such a link telling you that this specific link only served image/png (and
let's assume you only support image/gif), you could save a round-trip if
you had code looking at that hint. if you don't implement that code, then
you'll request image/gif and get a response telling you that you cannot
GET image/gif.

from our experience when designing web services, we want to give our
clients the ability to implement this level of sophistication. also, if
clients don't want to implement it this way, that's fine as well.
personally, and that's probably not all that accurate, i see hints as
something that allows clients to be "optimistically one step ahead" of the
usual REST flow: instead of having to go through OPTIONS/HEAD, you "trust"
the hints you found on the link. if the link lied to you, you'll miss out.

cheers,

dret.

Received on Tuesday, 11 June 2013 16:44:43 UTC