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? :-)
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? :-)
no subject
Definitely need to support posting to comms, but client protocol stuff is completely beyond me (trying to learn it though, in the process of updating Delicious Glue, simple enough for a newbie to get working, only, well, I can't do anything beyond the basics). Essentially, if a client won't let me post to a comm, it's not a client I can use. And I'm not a heavy Comm user.
no subject
And I can take care of the backend stuff, but trying to figure out a "nice" way to present it in terms of URLs -- perhaps
http://www.dreamwidth.org/interface/atom/entries (personal journal)
http://www.dreamwidth.org/interface/atom/afuna/entries (also personal journal)
http://www.dreamwidth.org/interface/atom/communityname/entries (some comm communityname)?
no subject
On most other platforms that I know of, username and blogname are always separate, so having a shortcut for people posting to just their journal may confuse those used to those standards.
But, given my complete lack of knowledge of this field, I don't know.
no subject
matgb.dreamwidth.org/interface/atom/entries
Is that possible or would it require too much duplication/redirecting?
Or does ATOM include auto detection in some way? I'm partially thinking mid term, if/when we get domain mapping setup, there will be some that'll make their setup appear completely separate from DW.
no subject
I need to think about the security implications though; maybe post to dw-dev as well. The big problem with domain cookies is that we generally keep as much as possible out of that space, so that if someone steals your domain-specific cookie (but not your master cookie), they can't make you do stuff to that journal.
This may not be an applicable concern since we use WSSE and/or digest auth for these.
But well, frankly I don't know enough off the top of my head to say with any certainty, so I'll want to look into it first.
And yes, there's auto detection. The service document lists available collections you can manipulate (edit, etc), which includes all the relevant links that you should need.
no subject
no subject
I do like the subdomain for the atom interface though, and the only thing I want to make sure of is that we're clear on potential security-related issues!