Such a clean, simple spec. There are still things to work out, but Joe has done an amazing job with the it. Why do we need XML-RPC or SOAP again when using REST is so much simpler that it makes "toolkits" unnecessary?
And, as I've stated elsewhere in the Wiki, it will be great if necho recommends a single wire protocol. Otherwise it's guaranteed that there will be a variety of them used, which will make true interoperability impossible, and impose a big burden on developers (and it will also require an additional discovery mechanism so that tools can detect which protocol is supported -- unless we want to force applications to hardwire implementations to tools from different vendors).
re: "it will be great if necho recommends a single wire protocol"
+1
+1
It is about the customers. If life is simple for developers with a single api then interoperability and reliability go up while costs go down and customers benefit from both.
RE: Joe's proposal
I can live with that. All POST and GET, with no PUT and DELETE. As much as I can like anything RESTish, I like it. Good job, Joe.
Diego:
Why do we need XML-RPC or SOAP again when using REST is so much simpler that it makes "toolkits" unnecessary?
That's a recurring theme here that I can't fathom. A toolkit will be necessary. It'll just be a Necho-specific one. You're still going to have to deserialize the Necho chunks, verify that the dates are dates, the booleans are booleans, and so on. We just won't be calling those toolkits "XML-RPC" or "SOAP".
The only technical advantage of REST is Dare's beloved layering of HTTP authentication and so on, which I predict will go almost completely unused in the wild.
With that said...
it will be great if necho recommends a single wire protocol.
Agreed. I think XML-RPC is a no-brainer, but if it gets shunted aside for political reasons, I'd prefer it be shunted aside completely. I'll already be supporting the MetaWeblog API via XML-RPC, so I certainly don't want to deal with multiple varieties of Necho on top of that. If it must be REST, let it be REST and that's it.
(I'm talking requirements here, BTW. I don't care what people support as options.)
Roger,
<blockquote>
That's a recurring theme here that I can't fathom. A toolkit will be necessary. It'll just be a Necho-specific one. You're still going to have to deserialize the Necho chunks, verify that the dates are dates, the booleans are booleans, and so on. We just won't be calling those toolkits "XML-RPC" or "SOAP".
</blockquote>
In the XML world, you do things like this with schema validation when parsing the XML stream. Since Sam has mentioned on several occasions that Necho will have both a W3C XML Schema and a RELAX NG schema I don't see where the need for a toolkit comes in.
The only technical advantage of REST is Dare's beloved layering of HTTP authentication and so on, which I predict will go almost completely unused in the wild
Considering that I run projects for both an aggregator that will support blog posting project and a weblog engine I'm sure there'll be at least two tools that will support HTTP authentication. Furthermore, there will be at least two tools that will refuse to connect to Necho implementations that do not use authentication unless overridden by the user.
Hmm. With a single 'required' wire protocol, there is no reason or incentive for anyone to implement an optional one, unless they control both ends of the wire.
I can live with that.
Re: single wire protocol -1. As usual we are over specifying I think. However its a great idea to concretize thus in terms of http and figure out what to do for other protocols, say even jabber from there.
One issue on modifying posts: wouldnt it be a good idea to have a postid/guid for that post on modification? The spec ought to make it easy for the server side tool to figure out exactly what entry to update methinks..
Ben Hammersley has a post that crosses into this region. In particular the paragraph that begins "Given enough will, everyone could be embracing the same API..." suggests very strongly that a common API will be good news for users but bad for (certain) vendors.
Dare:
In the XML world, you do things like this with schema validation when parsing the XML stream.
Validating the Necho package won't transform a W3CDTF date into a native DateTime object that I can actually use. Like it or not, moving to REST means building (or gluing together) a whole new batch of toolkits to take advantage of its strengths and work around its inefficiencies.
Of course, it's not the end of the world. And upon futher reflection, there's an argument to be made that the more wonky Necho's design becomes, the more it will encourage someone like Dave to expand and strengthen the MetaWeblog API, positioning it as an API for the Rest of Us. That kind of competition would probably be a very good thing, even if it means extra work supporting two completely different approaches.
Furthermore, there will be at least two tools that will refuse to connect to Necho implementations that do not use authentication unless overridden by the user.
I suspect pretty much all Necho implementations will need a way to authenticate users.
Another benefit of using XML over HTTP is the compatibility with XMLForms for editing, posting, deleting Well formed entries.
When the user wants to add/edit a weblog entry with his XMLForms capable browser, he simply clicks a link, the browser retrieves the XMLForm, the user populates it. And when the user submits the form, the well formed entry is simply posted to the publishing resource as XML.
The XML going over the wire is the same format as specified in Joe's proposal. When it has a schema associated, the XMLForms aware browser will even make sure that everything is nicely validated.
I consider XMLForms as one of the XML toolkits for doing REST style web services. The user/developer does not need to do any fancy XML marshalling, it is taken care of by the XMLForms implementation.
Also when the XML data has a schema associated, the XMLForms implementation will make sure that the entry is well-formed and validated. If, for example the issue date is editable, the XMLForms implementation, can show you a calendar popup field, where the user can only enter valid dates.
If I were to develop a weblog editor application, I would use an XMLForms implementation, that I'd embed in my application. No need to program XML marshalling, checking user dates, validating user entry or even constructing a nice form entry UI programmaticly. The XMLForms toolkit will do this for me.
This would allow me to spend more time on making the Weblog editor application more user friendly: more time to spend on look and feel (CSS) and usability and adding other more interesting features.
correction:
s/XMLForms/XForms/
I confused a the generic XForms term with the Apache Coccoon XMLForms implementation.
I'd like to suggest an alternative approach: