fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
fu ([personal profile] fu) wrote2011-01-11 12:54 am

Supporting Atom Publishing Protocol

I've been working on updating our implementation of the Atom Publishing Protocol for Bug 852, and I have a patch up there now.

Have several longish comments, but the short version is that our implementation was old to the point where I don't think any clients could use it, so I have felt free to break the old URLs while updating our implementation.

That is, I've removed support for:
http://www.dreamwidth.org/interface/atomapi/username/* (completely broken;
username had no effect on which journal the interface would use)
http://www.dreamwidth.org/interface/atom/feed
http://www.dreamwidth.org/interface/atom/post
http://www.dreamwidth.org/interface/atom/...

And I've implemented a new interface:

http://www.dreamwidth.org/interface/atom
GET: service document / used to discover the APP URLs we provide

http://www.dreamwidth.org/interface/entries
GET : lists the entries
POST: makes a new entry

http://www.dreamwidth.org/interface/entries/tags
GET: lists the journal's tags

http://www.dreamwidth.org/interface/entries/123
GET: retrieves entry 123
PUT: edits entry 123
DELETE: deletes entry 123


Does anyone have any concrete reasons I shouldn't push forward with this?

Also, any suggestions for how / whether to support posting to communities? What URL should we use? :-)
pauamma: Cartooney crab holding drink (Default)

[personal profile] pauamma 2011-01-20 11:19 pm (UTC)(link)
If using user-domain URLs for the service document, the username would have to be "who I'm posting *as*", since the document lets the client know what they can post *to*. Thus, the username would be redundant with the authentication credentials and would also require configuring per-account service documents (even if you only have one account, you can't rely on the client knowing out of the box that the service document for Dreamwidth is http://www.dreamwidth.org/mumble - you have to tell it the URL of the service document for post-as account "pauamma"). When you add people with multiple accounts, it only gets more tedious. So I would use www. for the service document.

Now the collections listed in the service document can have user-domain URLs - and in fact should, because they're just an Atom feed for the collection, just like the one used for syndication. But what the exact URLs shouldn't matter IMO, because a conformant client would just get them by retrieving the servce document, and not by using any programmed-in notion of what the collection URLs (and resource URLs) for Dreamwidth (Or any DW clone, or LJ clone) would look like. In fact, there's no reason to believe that they will remain unchanged as time goes on...

Another point worth keeping in mind for the future: the APP lets clients create media resources (which could conceivably be icons or pictures in whchever photo album thingy ends up having, or collections of links, for DW's memories/favorites/whatever feature). However, it also allows in-place modification, which requires a stable-across-revisions URLs. This doesn't fit the current URL scheme for icons (or the LJ/ScrapbookURL scheme for pictures), and any use of the APP for those features would have to deal with that.
pauamma: Cartooney crab holding drink (Default)

[personal profile] pauamma 2011-01-21 03:24 pm (UTC)(link)
Basically, yes.
pauamma: Cartooney crab holding drink (Default)

[personal profile] pauamma 2011-01-21 03:32 pm (UTC)(link)
I would favor the latter approach. In addition to making it easier for clients to have a "post entry to" dropdown like the web update page does, it would allow future extensions to add "community userpics" as a collection for each comm the user miantains.