First a bit of background.
The MetaWeblog API descripes a set of remote
procedure calls invoked via XML-RPC for interacting
with a weblog engine. One can perform actions like
post a new entry, edit an entry, and retrieve an
entry using the API. This means that people can use
weblog clients such as W.Bloggar and
Blogert
to edit and post their weblog entries to any blog
server that supports the API. I had planned to
implement this API for RSS Bandit so I could also
turn it into a blog client but decided against it
due to significant issues with the MetaWeblog API
and its ilk.
Below are the top three reasons I decided not to
implement the MetaWeblog API (or any other of the
current crop of APIs for posting/editing weblog
content) in
RSS Bandit but instead have decided to help Sam
Ruby in making Echo come to fruition.- Security: The
MetaWeblog API has no concept of security.
Passwords are sent in plaintext as parameters to
XML-RPC functions (i.e. they are sent in plain
text on the wire as part of the XML
message).
- Strongly Coupled To
XML-RPC: RSS and Joe Gregorio's CommentAPI
have shown that one can build applications that
retrieve and send XML documents from client to
server directly using HTTP GET and POST instead
of going through an added layer of indirection by
using exlicit RPC mechanisms.
One can retrieve messages with HTTP GET and send
them with HTTP POST. More importantly this means
that other facilities can be layered upon the
message format without having to complicate it.
For instance, security can be handled with HTTP
authentication instead of having to
unnecessarily complicate the API. Tracking
user identity can be done using HTTP cookies
instead of placing application IDs in the actual
message format like the
original Blogger API did.
Both the Blogger API and the MetaWeblog API are
extremely influenced by the RPC paradigm instead
of being influenced by the technologies that are
part and parcel of the WWW.
I also believe that there should be the API
should not just be tied to XML-RPC but should
have interfaces that utilize the XML Web Services
family of technologies like SOAP and WSDL not
just XML-RPC. There are many products and
toolkits that support SOAP/WSDL/etc plus more are
being built every day. It makes little sense to
me that almost everywhere else in the software
industry people are either exchanging XML
documents using
RESTian principles (i.e. HTTP GET and POST)
or the XML Web Services family of technologies
but when it comes to web content related
technologies there is this anachronism where an
arbitrarily different methodology is used.
This is not to say there aren't historic reasons
for XML-RPC's predominance in this area but that
in today's world there is no reason why industry
proven methodologies cannot be adopted in tandem
with the existing infrastructure.
- Limited
Functionality: The MetaWeblog API only
allows one to either post and edit blog
entries, fetch information about a specific
user or change the website template. This is a
drop in the bucket considering all the things
one would like to do with a weblog engine which
can be supported by the engine. For instance
there should be APIs methods for
- Retrieving entries
based on a search criteria (title, date,
category, etc)
- Posting comments in
response to someone else's blog entry
- Updating one's user
information.
- Managing one's
visible blogroll.
To put it simply, the MetaWeblog API is a good
first draft of a blog editing/posting API (which is
not far from the truth since it is just a
refactoring of v1.0 of the Blogger API) but it has
significant issues which cannot simply be addressed
by tweaking a method parameter here or a return
type there.
It is time for evolution to take place. Most of the
weblog community realizes this and is working
together to make this evolution happen. Sadly there
are some who view this as a disruption of their
legacy and instead of helping are attempting to
destroy the project. This is very unfortunate.