On 7/28/05, jack <jackjack@gmail.com> wrote:> I have this blog post of yours earlier today and think you are on
> track. We are interested especially in a Backpack-esque/del.icio.us
> simple-xml API that is versioned and ties into HTTP-Auth. So, I am
> interested in pushing this with you. I''ll be developing our
clients
> in concert with our API. At the moment we have a simple REST
> controller, which works well, but is a bit messy and discombobulated.
> We''re after a really clean solution here.
> Do you have more thinking along these lines?
I guess its all a matter of prioritizing what would matter most to
you, I''d prefer to go real-world-project driven than spec driven for
this second iteration, most definitely. Framework extraction has
proved to be a better planner than big-bang front design. The first
iteration was developed pretty much in isolation, echo chambers aren''t
good :)
I''ve taken longer than I thought to bounce it all around in my head,
but between those two blog posts and this message I think I have a
workable design that isn''t ivory tower.
Big bang notwithstanding, I do have some actual goals I want to address:
* Shift the framework to a document-based ideology. SOAP is grand and
all, and important to support, but simple document-based services
(that don''t require a massive supporting framework to generate the
requests) feel way more natural.
* Allow two modes of operation: "Encoded" and "Literal". In
"Literal"
mode, the server cares not at all what the request format is past a
certain point (the certain point being that where it has enough
information available to route the request). "Encoded" will be much
like we have now. In encoded mode, the client and server agree on the
document format (supported by descriptive declarations on the server
side), and the server pre-processes request documents into a simple
little DOM (or method call, for legacy RPC-style interfaces).
* Limit the amount of "extra work" you have to perform on the server
side to the minimum. If you''re writing "Literal" services,
since the
server is doing no preprocessing it really only needs to know where
the requests are going to arrive and how to send them on their merry
way.
* It would be handy to leverage Routing to attach your web services
wherever you want, a source of confusion seems to be where to send the
messages. Its quite teh static at the moment. This will force me to
better decouple dispatching neatly, which can only be a good thing.
The versioning portion is interesting, I''d not thought too much along
those lines. My thinking on that is that versioning is still really a
developer decision (policy + discipline). Using a document-based
approach makes versioning easier though. An extra or missing document
element is easier to work around than an extra or missing method
parameter. I''m not sure versioning should be encoded in endpoint URLs
though, but rather by using XML namespaces? Default namespace can be
v1, for example, and explicit a v2, no? I.e.
<Request>
<V1Tag>
</V1Tag>
<V2NS:Tag>
</V2NS:Tag>
</Request>
Supporting both versions..?
So, am I right in assuming you''d want to start first with the simple
XML approach for this next iteration (given you can support XML-RPC
and SOAP with current AWS)?
I have a few experiments that I have to pull together before I''ll have
something in a usable state to show you, but I think a weekend or two
of code jamming can get something really nice going (I''m bitserf on
IRC), with a shared SVN, if you want to join in (or not).
CC''d to rails-core in case some other folks want to pipe up. Any Stop
Energy will roll off as if nothing ;)
Leon