intertwingly

> A model of RESTitude.

I am highly enthusiastic about TrackBack's potential and was quite happy to see it become more RESTful with Paul Prescod's input. Wouldn't "a model of RESTitude" use DELETE and PUT rather then a query string parameter like &_mode= as TrackBack does? I know with the limitations opposed by browsers that this practice is accepted by RESTonians, but not as an ideal

For lack of enough coffee I'm splitting hairs already this morning, but the use of a "mode" query string instead of PUT/DELETE is a discussion I've been interested in having away from the REST-discuss list. Is there a better or simply alternate approach? Should an API like RESTLog support such a thing?

According to the specification, ?__mode=rss is used for "Retrieving TrackBack Pings" - something that seems quite appropriate for GET.

If I were to quibble, I would have preferred a more opaque URL approach - either via <LINK> or by putting the URL for this request in the RDF. Such an approach might be easier to cache.

"one could simply POST the RSS item that contains all the yummy goodies that one could imagine and let the server decide what pieces it wanted to keep and what pieces it chooses to ignore?"

What makes you think this can't be done with URL-encoded parameters?

Perhaps I should have said "instead of the existing URL encoded parameters". One could clearly URL encode the RSS item.

Do you see a practical advantage to doing so over, say, the way RESTLog does it today?

That's not what I meant.

Instead of adding, say, <keyword>foo</keyword>, you could simply add &keyword=foo. This has the benefit of being simple concatenation+encoding (instead of having to find the closing tag and putting stuff before it) and being relatively readable.

Aaron: OK - but that only works if the set of keywords are finite and known in advance. As new applications come along, I'd like them to be able to add new keywords without needing to resort to a centralized issuer of new keywords. To me, that's what namespaces provide.

Not being one for documentation when I have code to examine, the reference implementation of TrackBack does implement a delete method through a __mode parameter. Editing a ping is not implemented so a PUT is not necessary.

There is also a __mode=view which displays an HTML rendering of pings and __mode=rss which returns an RSS rendering of the same. (Should that be handled by a GET and content negoiation?) The "default action" when a request is made without a mode is to process it as a new ping. As of 1.1 this should be a POST which could differentiate itself from a view or rss.

Am I mistaken? Just testing my knowledge of REST principles with perhaps a healthy dose of shoe leather to come.

xmlns:foo=http://foo.example.net/&foo:bar=baz

Timothy - a delete operation using GET clearly violates the rules of HTTP. A delete operation using POST may be OK. A delete using DELETE is clearly OK.

Aaron - that clearly works.

Some people have XML parsers that would help with sorting this out, and XML's syntax might be helpful if the value associated with the keyword were to ever have internal structure, and there is some value in a consistent, canonical format, but all that being said, I don't have a problem with what you propose.

From the perspective of coding apps, for example when using CGI.pm, GET and POST data is parsed/accessed the same way. In my experience as a web developer I've never, ever cared which method was used. Since I never read the spec, I never really knew what the difference was between GET/POST, but with all the REST discussions, I became aware that a lot of people *really* care about the difference. I'm *still* waiting for a good explanation of why I should care. Is there any technical thing I'm missing, or is this purely a semantic issue? (I'm pretty sure it is the latter, but set me straight if it isn't.)

Brian: Although the difference GET and POST is not important to your CGI.pm based script, it is important to other entities handling your responses. Two examples are caching proxy servers and browser caches. These entities will cache GET responses, but not POST responses.

Yes, and one of those entities is the end-user. Look at an extreme example. The first CGI program I wrote was an intranet application that did POST for everything. And I mean everything. All the interaction was driven off a single URL. Don't do this. While the application had many pages the users were never able to bookmark them since the URL never changed. So they ended up sending screenshots back and forth to each other until I fixed the system.

Google cares. People who bookmark care. Caching proxies care. People who share links care. People who hit the back button care.

Lots of stuff cares about the GET/POST distinction.

Heck, this blog is a cgi. The page you are looking at can be retrieved via POST (be liberal in what you accept...). But if that were the only way you could get to it, you probably wouldn't.

OK, thanks for the info. Luckily in examining my work I've generally done the right thing, which is why I've never had any complaints from a very high-traffic app. It still would be nice to have a set of best practices outlined for schlubs like me. I suppose that is what REST is, but for whatever reason I have not found the material to be very accessible. FWIW, Roger Costello's slides are the best REST info I found that made me better aware of what this was all about, would love any pointers to better material.

Brian, you might like my own The Semantic Web for Web Designers. The HTTP section explains RESTian ideas.

I like Roger's slides better. Less propaganda.

It seems silly to explain something without explaining why you would want to use it.

... for example: "While there's certainly a lot of SOAP hype, I think the reality is less than some would leave you to believe."

... and false statements like: "Unfortunately, the SOAP spec requires all this extra information, even if it is useless for most purposes."

As I said. Roger's slides are better.

I'm happy to take corrections.

Aaron: omit needless words. Is this supposed to be a SOAP rant or a proscriptive explanation of the semantic web as you envision it?

If it is meant to be the latter, then since the future you envision apparently does not include SOAP, I would recommend dropping all references to it.

Try it, I think you will find that your paper will be stronger.

As I've been working on Roller's further-reading feature for the 0.9.7 release, which is essentially the same as Mark Pilgim's automatic backlinks and further reading implementation, I've been trying to learn more about other weblog entry linking...

The Comment API works by POSTing a XML document to a URI. TrackBack works in nearly the same way but POSTs data in the format of an HTML web form. The only difference between the two is the data format, i.e. their mime-types. And Aaron Swartz may...

Pingback from TIG's Corner

Recently I was asked what is the difference between Ping- and Trackback. I tried to find an answer, but in the end, I just "talked around the hot pudding" (literal translation from german;)... Some references: Trackback Pingback Sam Ruby discussing ...

Pingback from blog@bitflux :: Ping- und Trackback

Recently I was asked what is the difference between Ping- and Trackback. I tried to find an answer, but in the end, I just "talked around the hot pudding" (literal translation from german;)...

Some references:
Trackback
Pingback
Sam Ruby discuss...... [more]

Trackback from blog@bitflux

There was quite a bit of chatter a while back about merging the notions of blog Comments and Trackbacks. Sam's blog, for instance, treats them all the same. In the... [more]

Trackback from snellspace

Clay Shirky on customer-owned networks and the Lazy Web, and reactions.  Zeldman on Safari.  Les Orchard on personal web proxies.  Brian Donovan on separation of content and presentation.  Various ways to import bookmarks into... [more]

Trackback from dive into mark

WIBNI Trackback 2.0.... [Sam Ruby] Sam adds details about Trackback used in LazyWeb, and while at it LazyWebs Trackback itself: fun recursion :-) PS: I wonder if the LazyWeb noun will take off as a verb. I love the english language for this...