gmane.comp.web.services.rest

RE: Bit Off-Topic: yahoo groups is a pain

Glenn Block — 2012-05-16T15:07:20

Same

Sent from my Windows Phone
------------------------------
From: mike amundsen
Sent: 5/5/2012 7:45 AM
To: Jakob Strauch
Cc: rest-discuss< at >yahoogroups.com
Subject: Re: [rest-discuss] Bit Off-Topic: yahoo groups is a pain

yeah, i use email to interact here.

mca
http://amundsen.com/blog/
http://twitter.com< at >mamund
http://mamund.com/foaf.rdf#me

On Sat, May 5, 2012 at 4:31 AM, Jakob Strauch <jakob.strauch< at >web.de> wrote:
little bit annoying?
recipient. Hellloo? it is a group discussion, what should be the default
here? Or why not provide at least a "reply all" link? I don´t know how many
double posts i received (and sent!) because of that "feature".
was clicking around for 10 minutes until i found something, where i could
phrase a question, just to discover, that the FAQ was searched by this
phrase. Nice...
these little (un)information canapés spread over every page? The layout
from the 90ies?
discuss group application.

Re: Re: Making ETags mandatory

Julian Reschke — 2012-05-16T13:20:54

<http://greenbytes.de/tech/webdav/rfc6585.html#status-428>

Re: Making ETags mandatory

Paul K Moore — 2012-05-16T10:22:40

For others stumbling upon this thread, there's also a draft RFC that
introduces '428 - Precondition Required'
See Jan's response here:
http://tech.dir.groups.yahoo.com/group/rest-discuss/message/18802
<http://tech.dir.groups.yahoo.com/group/rest-discuss/message/18802>
Best regards
Paul--- In rest-discuss< at >yahoogroups.com, Jan Algermissen
<algermissen1971< at >...> wrote:

Re: Re: Rel attributes?

mike amundsen — 2012-05-05T23:10:41

Jørn:

what i am aiming for is judgement.  as designers of solutions
(architects, programmers, implementors, etc.) we make decisions. we
decide to use one option over another. we decide some set of possible
options are [fill in some word that is more acceptable for you than
"bad" here] and one of the possible options is "good" (or some other
word you find acceptable).

FWIW, what i am after here is to give us all a chance to talk about
our choices. i've not used words like "right" "wrong" here. i've been
careful to use several important words with quote marks around them to
indicate that those words have a qualitative value, not quantitative.
i've provided more than one possible ways to interpret and answer the
questions i pose.

what i am doing here is offering choices that are, essentially,
functional equivalents. some would select one option; some another. i
am asking for ppl to make explicit their choices and help me learn why
they made them.

for me, there is no "right" answer. and every answer is an o

Re: Re: Rel attributes?

mike amundsen — 2012-05-05T14:54:00

As a follow up affordance designs ideaa. check out this thread from
1997 when Marc Andreesen decided to add support for figures in his
"Internet Browser".

He proposes this[1]:
<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">

Tim Berners-Lee suggests reusing the HTML.A tag[2]:
<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>

other options are offered including[3]:
<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">
<INCLUDE HREF="...">
<A HREF="..." INCLUDE>See photo</A>

Which of these options relies on more "out-of-band (not-in-message)"
information?

[1] http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html
[2] http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html
[3] http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.html

mca
http://amundsen.com/blog/
http://twitter.com< at >mamund
http://mamund.com/foaf.rdf#me



On Sat, May 5, 2012 at 10:17 AM, mike amundsen <mamund< at >yahoo.com> wrote:

Re: Bit Off-Topic: yahoo groups is a pain

mike amundsen — 2012-05-05T14:45:17

yeah, i use email to interact here.

mca
http://amundsen.com/blog/
http://twitter.com< at >mamund
http://mamund.com/foaf.rdf#me



On Sat, May 5, 2012 at 4:31 AM, Jakob Strauch <jakob.strauch< at >web.de> wrote:

Re: Re: Rel attributes?

mike amundsen — 2012-05-05T14:20:45

If i understand your question, the actual mapping of the protocol
details to the message design differs depending on the protocol used.

for an example of a very similar design (list, item, query), check out
this blog post that shows both HTTP and FTP "bindings" for the message
design:
http://www.amundsen.com/blog/archives/1041

mca
http://amundsen.com/blog/
http://twitter.com< at >mamund
http://mamund.com/foaf.rdf#me



On Sat, May 5, 2012 at 8:58 AM, Paul Moore <paul.k.moore< at >lineone.net> wrote:

Re: Re: Rel attributes?

mike amundsen — 2012-05-05T14:17:12

Jørn:

do you think the following design elements are also "bad"?

HTML.IMG
HTML.A
HTML.LINK
HTML.IFRAME
HTML.SCRIPT

mca
http://amundsen.com/blog/
http://twitter.com< at >mamund
http://mamund.com/foaf.rdf#me



On Sat, May 5, 2012 at 8:07 AM, Jørn wildt <jornwildt< at >gmail.com> wrote:

Re: Re: Rel attributes?

Paul Moore — 2012-05-05T12:58:57

Mike,

Irrespective of the (en)coding variants below, how are 'create' and 'update' defined in your media type for this context?

Paul

On 5 May 2012, at 06:04, mike amundsen wrote:

Re: Rel attributes?

Jorn Wildt — 2012-05-05T12:10:05

In my opinion it is bad. The server should include http method and payload format (but you only asked to compare the two formats). The client should only know the "action" name and the set of parameters to transfer - it is then left to the server to specify the rest in a form language defined by the media type of the current message.

/Jørn

--- In rest-discuss< at >yahoogroups.com, mike amundsen <mamund< at >...> wrote:

Re: Re: Rel attributes?

mike amundsen — 2012-05-05T10:39:31

note that neither option contains: http method or encoding information.

that is "out of band" knowledge in these designs.

is that "good" or "bad" here?

mca
http://amundsen.com/blog/
http://twitter.com< at >mamund
http://mamund.com/foaf.rdf#me



On Sat, May 5, 2012 at 6:26 AM, Rushforth, Peter
<peter.rushforth< at >nrcan-rncan.gc.ca> wrote:

RE: Re: Rel attributes?

Rushforth, Peter — 2012-05-05T10:26:32

Hi Mike,

A couple of my replies through the yahoo web interface have gone awol.

Thanks for this.

Both rely on the hypermedia documentation, per Roy's hypermedia-apis-must-be-hypertext-driven post.
The first option is simpler, so it gets my vote, in the absence of a defined use for the extra markup.

Cheers,
Peter
________________________________________
From: mca< at >amundsen.com [mca< at >amundsen.com] on behalf of mike amundsen [mamund< at >yahoo.com]
Sent: May 5, 2012 1:04 AM
To: Jørn Wildt
Cc: paul_k_moore; Rushforth, Peter; rest-discuss< at >yahoogroups.com
Subject: Re: [rest-discuss] Re: Rel attributes?

Jørn, Paul, Peter:

here are two options for a hypermedia affordances in a media type
design that supports writing new and updating existing resources:

<create href="..." >...</create>
<update href="...">...</update>
OR
<write href="..." action="create">...</write>
<write href="..." action="update">...</write>

Which relies on more "out-of-band" knowledge?
Which is a "better" design and why?

mca
http://amundsen.co

Bit Off-Topic: yahoo groups is a pain

Jakob Strauch — 2012-05-05T08:31:07

I don´t know, if i´m the only one, but isn´t the yahoo groups webpage a little bit annoying?

1. Reply: When you click reply, the messages sender is always the default recipient. Hellloo? it is a group discussion, what should be the default here? Or why not provide at least a "reply all" link? I don´t know how many double posts i received (and sent!) because of that "feature".

2. Help/Feedback: Ever tried to provide feedback to yahoo? Have fun! I was clicking around for 10 minutes until i found something, where i could phrase a question, just to discover, that the FAQ was searched by this phrase. Nice...

3. Design: I don´t know, where to start. Maybe the two search fields? All these little (un)information canapés spread over every page? The layout from the 90ies? 

In a nutshell: These "affordances" make me think to much for a simple discuss group application. 

Had to be said...

Re: Rel attributes?

Jakob Strauch — 2012-05-05T07:59:41

Hi Mike,

i guess the second design is easier to evolve by defining more valid action values without breaking the client, which can ignore unknown actions. 

As far as i can see, the out of band knowledge is pretty much the same, isn´t it?

Jakob

--- In rest-discuss< at >yahoogroups.com, mike amundsen <mamund< at >...> wrote:

Re: Rel attributes?

Jorn Wildt — 2012-05-05T07:50:05

Both examples allows the server to add new elements without breaking existing clients so both are fine with me. New clients has to look for new stuff anyway - be it as new elements or as new actions/relations. So the same amount of out-of-band knowledge seems to be required.

Personally I prefer the generic <write> since the client won't have to add new parsing capabilities if it already supports collections of named <write> elements.

/Jørn


--- In rest-discuss< at >yahoogroups.com, mike amundsen <mamund< at >...> wrote:

Re: Re: Rel attributes?

mike amundsen — 2012-05-05T05:04:40

Jørn, Paul, Peter:

here are two options for a hypermedia affordances in a media type
design that supports writing new and updating existing resources:

<create href="..." >...</create>
<update href="...">...</update>
OR
<write href="..." action="create">...</write>
<write href="..." action="update">...</write>

Which relies on more "out-of-band" knowledge?
Which is a "better" design and why?

mca
http://amundsen.com/blog/
http://twitter.com< at >mamund
http://mamund.com/foaf.rdf#me



On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw< at >fjeldgruppen.dk> wrote:

Re: Re: Rel attributes?

Jørn Wildt — 2012-05-04T20:45:40


I would say that you can do rel="CreateWithPost" and declare that in the 
link-rel documentation. But you loose something by doing so: allowing the 
server to specify HTTP method and payload encoding at runtime (since that 
knowledge would have to be a hardcoded part of the link-rel knowledge).

Had the link "Create" instead lead to a form of some kind then the form 
could specifiy HTTP method at runtime, thus letting the server evolve over 
time (changing HTTP method) without updating the clients (as they are 
expected to understand the full form language).

I haved tried to illustrate this in 
https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ - 
check the "evolving server, stable client" scenarios in example 1, 2 and 3.

/Jørn

----- Original Message ----- 
From: Rushforth, Peter
To: paul_k_moore
Cc: rest-discuss< at >yahoogroups.com
Sent: Friday, May 04, 2012 2:28 PM
Subject: RE: [rest-discuss] Re: Rel attributes?



Hi Paul,

In atompub, the rel="edit" link relation means you can PUT

RE: Re: Rel attributes?

Rushforth, Peter — 2012-05-04T16:19:36

Hi Paul,

Fair enough, I did not go back to the spec to quote it, but throw GET in there too.

How did you get here in the first place?  When this representation is taken out of its habitat,
what is it/where did it come from/how can I get a fresh copy?  


remember that the collection resource is not the member resource.  So while a feed informs you of its members, it does not guarantee that the entries are complete.  That is REST for you - no guarantees that the representation is the resource.  And anyway, you haven't done a GET on the Member resource, just the Collection, so any Allow header you have received to date is about the Collection resource. 

Well of course you would want to do a GET before doing a PUT, unless you don't care what the resource says.  You have a point with Allow, I think.  I think you are arguing that a hypermedia format definition should associate method,rel,type "coordinates".  Am I wrong?

Cheers,
Peter

Re: Re: Rel attributes?

Paul Moore — 2012-05-04T15:38:57

Peter,

Caveat: I am not an ATOM expert, happy to be corrected.

I have investigated the 'edit' link relation previously and concluded that the semantics are confused.

The definition from ATOMPUB is:

"The value of "edit" specifies that the value of the href attribute is the IRI of an editable Member Entry. When appearing within an atom:entry, the href IRI can be used to retrieve, update, and delete the Resource represented by that Entry..."

So, actually 'edit' means GET, PUT, DELETE (in at least one context :-).  We could have a conversation about what 'self' means (a restatement of GET?), but let's park that for a moment.

Then latterly in the Spec there's this, which informs us that the member entry in a feed may not be complete. 

"Clients MUST NOT assume that an Atom Entry returned in the Feed is a full representation of an Entry Resource and SHOULD perform a GET on the URI of the Member Entry before editing it."

This is (at best) annoying for a user-agent which has to either (i) understand the compl

RE: Re: Rel attributes?

Rushforth, Peter — 2012-05-04T12:28:35

Hi Paul,

In atompub, the rel="edit" link relation means you can PUT or DELETE to the href.

Also in atompub, app:collection/accept/text() tells you you can POST the app:collection/< at >href whatever MIME types are
listed in the app:accept text().

Going by that as an exemplar, it seems to me that it is the hypermedia format which is defining what can and can't be
done against the URL.  Maybe that is out of band knowledge, but then again, knowing what < at >method="POST" means
could be considered out of band too.   It has to be written down somewhere and agreed to.  So the sharing of the semantics
widely is key to interoperability.  Hence a public link relations registry.   It is the shared semantics that allows us to
program user agents to do predictable things when they come across a particular hypermedia construct.

Maybe it is important that when a GET is done on a resource, that the response metadata also declare the available methods.
Message metadata is authoritative.

But you should not have to do that GET, b

Re: Rel attributes?

paul_k_moore — 2012-05-03T15:00:25


William

This is very useful - thank you.

Just to confirm my (refined) understanding here, I consider the meaning of 'rel' to be an orthogonal concern to the HTTP methods.

To expound slightly, I had erroneously conflated the HTTP methods (avaialble at the target URI) into the meaning of 'rel'.  If we consider the following two examples:

Example 1: Use of a 'rel' such as 'http://relations.example.com/order' reasonably conveys to the user-agent that there is something 'order'-like at the target URI.  It is then up to the client (the client intent) to follow this rel (using an implicit GET request) to retrieve the representation of the 'order'-like thing (as rendered in a specific media-type).

Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to (unreasonably) convey that the user agent can POST an item of the type communicated by it's current context.  This is the problem, I don't need to 'say' to the user-agent that it can POST at a specific URI, because the available HTTP methods tel