It’s just data

WIBNI Trackback 2.0...

Clay Shirkey: A LazyWeb item in RDF has only four elements, set by the Trackback spec -- title, link, description, and date. Thus almost all the onus on filtering the feed is on the subscriber, not the producer. An RDF format with optional but recommended tags (type: feature, schema, application, etc; domain: chat, blog, email, etc.) might allow for higher-quality syndication, but would be hard with the current version of Trackback

Trackback 1.0 used HTTP GET to transfer state data from the client to the server, a no-no from a REST perspective. I noticed this, suggested to Paul Prescod that he work with Ben, and they did all the hard work.  The result was Trackback 1.1. A model of RESTitude.

Now along comes another application which would like to extend this API. Wouldn't It Be Nice If instead of URL encoded parameters, 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?

This is how the RESTLog API works today...


> 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?

Posted by Timothy Appnel at

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.

Posted by Sam Ruby at

"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?

Posted by Aaron Swartz at

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?

Posted by Sam Ruby at

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.

Posted by Aaron Swartz at

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.

Posted by Sam Ruby at

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.

Posted by Timothy Appnel at

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

Posted by Aaron Swartz at

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.

Posted by Sam Ruby at

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.

Posted by Sam Ruby at

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.)

Posted by Brian Buck at

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.

Posted by Bravada Zadada at

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.

Posted by joe at

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.

Posted by Aaron Swartz at

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.

Posted by Sam Ruby at

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.

Posted by Brian Buck at

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

Posted by Aaron Swartz at

I like Roger's slides better. Less propaganda.

Posted by Sam Ruby at

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

Posted by Aaron Swartz at

... 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.

Posted by Sam Ruby at

I'm happy to take corrections.

Posted by Aaron Swartz at

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.

Posted by Sam Ruby at

Trackback, pingback, linkback, etc.

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...

Excerpt from Blogging Roller at

Mime-type intersection

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...

Excerpt from Well-Formed Web at

Pingback from TIG's Corner

at

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 discussing ...

Pingback from blog@bitflux :: Ping- und Trackback

at

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

at

More On The Evolution of Weblog APIs: Ping, Trackback and Comments

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

at

In brief: 8 Jan 2003

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

at

Sam Ruby about LazyWeb LazyWebs Trackback: Fun recursion

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...

Excerpt from Patrick Chanezon: Collaboration at

Add your comment