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