Joe
Gregorio: There is a lot of discussion
on the proposed Blogger API Version 2.0 and
Ben brings up some very good points. This gives me a
chance to trumpet REST in general and RESTLog specifically in how
they solve these problems.
Seed planting time.
What if RESTLogImpl.py allowed for the posibility that
<item> elements it receives using an HTTP PUT may be enclosed
in Envelope and Body elements, as described
here. All I am asking is that these be ignored... the one
exception is if some XML element contains a mustUnderstand
attribute with a value of "1", then you return an appropriate SOAPFault.
I'm not suggesting that such an envelope be required, or that
any other changes be made to the API. Merely that it be
tolerated if it were present.
I can donate the Python server code for generating a SOAPFault
message.
Timothy
Appnel: If you havn't seen it, Joe's prototype and
RESTful API can be found here. A
RESTful API for updating weblogs is a good idea.
Overall, I'm positive on the notion of a Well Formed Web...
though I would actually rather see a Valid Web. The ability
to automatically discover and generate dynamic or static proxies is
a powerful notion. One that need not necessarily require that
all methods are POSTs or that actions be embedded inside the
data.
...change.
Blogger API 2.0. Sigh. It looks like the future of
blogging clients and servers is to have more code in if/switch/case
statements and configuration options than actual logic.
What's worse is a future where - despite all the interfaces being
"open" - the only real guarantee you will have is that vendor A's
clients will work with vendor A's servers. That's called
vendor lock-in.
At the time the MetaWeblog APIs were written, I wrote this.
Deja vu all over again.
IMHO, the right thing to do is to focus on the bits and bytes
that go across the wire. Define an XML message for each
interaction. In fact, divide the XML message into two parts -
a header which contains "login" information, and a body which
contains "post" information. Allow tool specific
extensions through namespaces to support "filters", "actions",
etc..