It’s just data

XML-RPC, SOAP, and/or REST

Dave Winer: Here's the Wiki page where people are deciding whether to use XML-RPC and/or SOAP. You can express your opinion if you like. That's how it works.

Excellent!  Now lets see if we can have a respectful dialog on the subject?  No hand waving or grandstanding, simple facts.  I say this because this is an area ripe for flamage from all camps, not just XML-RPC and SOAP, but also REST which needs to be included in this discussion, IMHO.  OK?

To start things off, Dave Winer's has expressed his opinion as XML-RPC keeps the barrier to entry super-low. There are 78 toolkits. SOAP interop is harder. Keep it simple. And if you asked me if you can use HTTPS to transport XML-RPC I would say yes. HTTPS is HTTP. Strongest reason to use XML-RPC: EVERY BLOGGING TOOL AND EDITOR TODAY SUPPORTS XML-RPC. IF IT AIN'T BROKE, DON'T FIX IT.

My current leanings matches Mark Baker's: don't want any RPC interface, be it XML-RPC or SOAP. Gimme a RESTful interface, optionally RESTful SOAP. - however, I would like to see more data before I cast my vote.

Misha Dynin has already sketched out what a SOAP binding would look like.  Take an echo entry, put it in a body, add a header.  Done.

I'm guessing here, but Mark Baker's example would probably look a lot more like this.

From what I have seen, most XML-RPC interfaces would not document this at the wire level at all, but would describe this in terms of structs.  Anybody care to sketch out what this would look like so that we can compare apples and oranges?  Just so things aren't a moving target, lets limit the scope of this to the 2003/07/01 snapshot.


I used to be scared of SOAP.  Until one evening we had dinner with Sam in Boston, and he explained the beauty of it.  I had hear it before, but for the first time, I could show how ignorant I was and repeat the same question over and over, until I got the feeling that what Sam was telling me was right.

Mono recently implemented its Web Services soap code.  Thanks to Sam for demistifying it.  I would have been bogged down and depressed with Section 5 for a long time otherwise. 

That being said, Lluis Sanchez, C# uber hacker, implemented Soap Section 5 encoding in two days, just to prove that his XmlSerializer architecture was easy to extend.

Hope others realizes how simple soap can be. 

Miguel.

Posted by Miguel de Icaza at

Yup, you got it Sam.

Posted by Mark Baker at

Sam -- it might look something like this:

http://ranchero.com/echo/xmlrpcexample.txt

This is meant to be equivalent to the example at the top of this page:

http://www.intertwingly.net/wiki/pie/BloggerProposals

The point about using XML-RPC is less what it looks like: it's about how so many people already use it and how it easy it is to use.

Yes, SOAP may be cool too, but it's not current practice for weblogs, and I personally have yet to see a really good reason not to go with what people are doing already.

Posted by Brent Simmons at

XML-RPC, SOAP, and/or REST. Dave Winer: Here's the Wiki page where people are deciding whether to use XML-RPC and/or SOAP. You can express your opinion if you like. That's how it works.  Excellent!  Now lets see if we can have a respectful...

Excerpt from bLOGical at

Forget XML-RPC and SOAP, both are more than is needed.

Problems I see with using XML-RPC are that it ties itself to HTTP and that the code to receive the entry must know about XML-RPC.

Issues with SOAP are listed elsewhere, whether they are accurate or not is open to interpretation :-)

I can see now how simple the code is for both sending and receiving if all the post is sent as is an XML fragment containing the entry. This could also be done extremely simply in an Apache module for example - no need for databases, just files, nice.

So my choice for a initial transport is definitely POST/GET/PUT/etc. over HTTP using entry reading format.

Having the entry sent as just an XML fragment should also make tying in other types of posting tools simpler.

Posted by Peter Wilkinson at

Brent, it looks like you have described an API which has five parameters in a specific order.  Either I am missing something, or there are no provisions for extensibility with such an API - by this I means supporting arbitrary namespace qualified elements.

My first reaction was to ask you how such things should be handled?  However, on second thought, perhaps you are advocating a simple, streamlined XML-RPC based API to handle the most common case?  Perhaps as an adjunct to a full function non-XML-RPC based mechanism?

I could speculate further, but perhaps instead you could comment on what you are proposing?

Posted by Sam Ruby at

Excellent point Sam re. extensibility.

One thing that I saw on the wiki that worried me was mention of server side blogging tools dropping parts of the entry that they didn't understand, it should really be the case that I can toss into an entry any extensions that I like and have then retained in the feed when read.

This is probably not possible in current tools but it would be fairly straightforward to handle, maybe a RFC style SHOULD about this in the resulting spec would be helpful.

Posted by Peter Wilkinson at

Sam, here's what an echo xml-rpc feed would look like:
http://www.intertwingly.net/wiki/pie/SampleXmlrpc

Posted by Adriaan Tijsseling at

(not)Echo API

There's a post on Sams blog about whether to use xml-rpc, soap and/or rest for the (not)echo weblogging API. And a raging discussion on the Wikias well. Having implemented the Blogger API, Metaweblog API and RESTLog in the past, I'm all for a... [more]

Trackback from Simon Fell > Its just code

at

please!, no more API's with passwords in clear text.

Posted by Simon Fell at

Several comments...

Sam:

From what I have seen, most XML-RPC interfaces would not document this at the wire level at all, but would describe this in terms of structs.

People using ColdFusion MX's incredibly simple SOAP support would do much the same thing.

Peter:

it should really be the case that I can toss into an entry any extensions that I like and have then retained in the feed when read.

Not happening with me. :) For several reasons:

(1) If there isn't a spot in the database for the data, there just isn't a spot. I could personally work around that because I use a combination of a database and filesystem storage of XML, but many folks couldn't.

(2) Even if I did let the extended data through, it wouldn't end up in the feed without a way to describe it in the user's template.

(3) For security and business reasons, not all users are created equal. Some can do X with their blogs, and some can do both X and Y. It wouldn't make a lot of sense to let them bypass such restrictions by inserting random data at whim via the API.

PLEASE NOTE: I'm not arguing against the creation of a tool that will accept anything you throw at it. I'm arguing against the idea that all tools should work that way.

Simon:

please!, no more API's with passwords in clear text.

Personally, I'd prefer to handle authentication via cookies and not look to the API for it. However, I recognize that many folks will be more comfortable with passwords in the clear, and I see no reason not to support them. That is the existing convention, after all.

Posted by Roger Benningfield at

+1 for a RESTful solution. Both XML-RPC and SOAP are unnecessary complications on top of REST. Worst case if you needed one, though, it should be SOAP. This isn't a protocol for today and next week, it's a protocol for years to come. XML-RPC should be well and buried by then.

Posted by Brad Wilson, The .NET Guy at

Dare Obasanjo

Roger,
"Personally, I'd prefer to handle authentication via cookies and not look to the API for it. "

What's the difference between using cookies for authentication and passing them in XML message? They are both insecure as all get out since the password is passed around in plain text either way.

Message from Dare Obasanjo at

Sam -- yes, my example is an n-parameter procedure call, because that's what the example looked like to me.

But here's the deal: you can use arrays and structs (dictionaries) in XML-RPC. Structs are great for extensibility. (As in the metaWeblog API.) Arrays are great for things like a list of categories.

If you can describe a weblog post with strings, dates, numbers, booleans, arrays, and dictionaries, you can do it in XML-RPC.

I can assert this with utter confidence because lots of software already does this.

It's beside the point to debate whether XML-RPC allows for extensibility, or whether or not it's suited to create new weblog posts -- these are just facts. It's being used this way right now, and has been used this way for years.

Which is why I advocate it. Not because it's perfect, but because of all the XML-RPC experience and software that people who write weblog systems and editing tools already have.

New syndication and archiving formats and a new API is already a ton of new stuff.

Posted by Brent Simmons at

Regarding cookies and authentication - guys, cookies don't authenticate anything.  They can help establish a "session" (or link credentials across sessions), but credentials need to be used for authentication before a cookie can be issued.  And they have to get there somehow.

But HTTP authentication doesn't necessarily need clear-text.  For example, HTTP digest works without sending passwords in the clear, and is implemented by many (most?) toolkits.

Posted by Greg Reinacker at

Dare Obasanjo

Brent,
  I have one or two questions about XML-RPC based on various ways I've seen it used.

1.) Do implementations of XML-RPC have to support XML namespaces or only XML 1.0?

2.) Does XML-RPC have a problem with elements that have attributes? If not why is there a hacky proposal for getting elements with attributes to work with the MetaWeblog API at http://www.xmlrpc.com/stories/storyReader$2406 ?

Message from Dare Obasanjo at

Dare:

What's the difference between using cookies for authentication and passing them in XML message?

For many implementations, there probably would be no difference at all. In my case, username and password info is encrypted before being stuffed into a client cookie, and is only decrypted on the server during the login process.

Note that I'm not suggesting Necho should support that kinda thing. I'm just answering the question.

Posted by Roger Benningfield at

Dare -- XML-RPC doesn't support namespaces. Tags in XML-RPC don't use attributes.

XML-RPC is a serialization of data types that most programming languages have in common.

It's not that XML-RPC has a problem with XML elements that have attributes, it's that it's not thinking about things that way. You don't include straight RSS or Echo or whatever in XML-RPC. You send data that describes a new weblog post.

A weblog post is a dictionary with several items. (Title, body, author, etc.) Any time you have a complex object, you use a dictionary or an array.

If you're absolutely wedded to using the Echo syndication format for everything, even for the bits passed around by the editing API, then XML-RPC isn't suitable.

Posted by Brent Simmons at

Let me strengthen Brent's statement. By defining the API as using nested structs (dictionaries) which contain values, you can maintain both forward and backward compatibility in the API.

The basic API implementation would require the same elements that a well formed log entry does, and everything else is optional.

Both clients and servers could simply ignore (or just store for possible future reference) optional members (and nested structs and their members) that they don't have code for dealing with. Thankfully, that's what 'optional' means.

Any given pair of client and server can then easily interoperate on a highest common denominator basis. It would probably be nice though if the client could query the server as to which optional extensions to the entry model (and the API) it understood.

Posted by Michael Bernstein at

Heh. In case it's not clear, my comment was regarding Brent's 00:56 comment.

Posted by Michael Bernstein at

Brent: I think Dare was referring to the way Dave chose to model attribute-laden RSS elements within the MW API.

Y'know, the whole...

<struct>
<member>
<name>myattribute</name>
<value>foo</value>
</member>
<member>
<name>_value</name>
<value>bar</value>
</member>
</struct>

...kinda thing. It's one of the problems with the MW API, in my opinion. There isn't enough consistency in the way individual structs are generated.

For example, an element like <description> is normally just a name and a value. But if <description> were an empty element with only attributes, then it would be a struct full of names and values. And if it has both attributes and a value, then it is a struct full of names, values, and a special member called "_value" thrown in for good measure.

Nechofying that wouldn't be a huge task, though. It could be as simple as saying that all elements should be represented as structs, whether they contain attributes, values, or both.

Not a huge thing.

Posted by Roger Benningfield at

Roger,
I have a blog server tool that would behave exactly as you describe - a fixed database schema doesn't have room so it would drop it on floor. I've also knocked together another that stores xml directly so it could keep it.

Those tools that do drop some of the data should definitely report back in some way that they have.

I could see this as a point of differentiation between competing clients and servers - all remaining interoperable since they understand the base format with some having useful extras. Good thing or bad? I think it would be good.

Posted by Peter Wilkinson at

I've seen some people calling for Echo to support API interactions in SOAP, XML-RPC and REST, since they each have their supporters and can pretty much do the same things if you twist them hard enough. I don't like this idea personally as it's ridiculous to ask Necho implementors to implement three different APIs, but I don't see any reason people can't build API "proxies" to allow alternative methods to be used. Dave Winer has his Google SOAP-to-XML-RPC proxy, people who want an XML-RPC interface to Necho can build something similar (should SOAP be decided as the main API method). The same goes for REST.

Taking this approach to its logical conclusion, someone is bound to write an XSLT stylesheet to transform Necho feeds to RSS and back again. After all, It's Just Data ;)

Posted by Simon Willison at

I just wrote up a design sketch for a minimal API based entirely on HTTP POST; I've called it a "Web API" rather than RESTian as I think that term is generally poorly understood, and anyhow the web predates Roy's dissertation :).

Just a sketch as I said: http://www.tbray.org/ongoing/When/200x/2003/07/03/HTTP-RSS

Posted by Tim Bray at

Dare Obasanjo

Brent,
  Thanks. You've given me good justification why I'll add my vote to -1 for XML-RPC.

Message from Dare Obasanjo at

I like Tim's suggestion.

I am confused by the description of a document literal mode for SOAP. I thought that would be able to handle the same on the wire format as Tim's example. If so that surely would be great as then a server could choose to use SOAP or not.

Either way I would much prefer plain WebApi/REST and not SOAP or XML-RPC.

DaveWarnock

Posted by Dave Warnock at

-1 for SOAP, +1 for a RESTful interface, and a "don't care" for XML-RPC.

Stupid thought: can't we use a single parameter (except authentication related parameter) whose value would be the content of a "normal" Echo <entry> (ie. a piece of XML)?

Posted by anonymous at

Peter:

Those tools that do drop some of the data should definitely report back in some way that they have.

I dunno... I think it might be better to leave that to an autodiscovery process. Let the client ask the server about its capabilities in advance, and then simply shut off any unsupported features. I figure it's better to prevent the failure than report on it.

Posted by Roger Benningfield at

I like Tim's suggestion too, but I see a problem with permissions. If blogger were going to use this, they'd need to create a POST handler for each blog. And the username and password have to be transmitted using HTTP security.
I'm not sure how well this is supported in the various HTTP packages for the various programming/scripting languages.

SOAP would be much easier in this case, because blogid, username and (encrypted) password can be sent in the header of the SOAP request, as Misha showed.

Posted by Sjoerd Visscher at

GoogleAds

[@473] So Erik... “How did you get accepted by Google AdSense,” you ask? Well, I don't really know. But here's what I did. As you know, when I submitted my site I was flat out rejected. The form letter I received indicated that you could...

Excerpt from Erik's Weblog at

Roger,

I dunno... I think it might be better to
leave that to an autodiscovery process.

Good point, this makes sense.

Also having a look at the proposals for posting  an entry it looks like people are leaning to echoing (no pun intended) back the post with id's added etc. so that the client tool could quite easily pick up that there was part of the entry dropped.

My use case for this is to have simple command line scripts (perl/python etc) send fragments via curl for collecting data from remote hosts so being able to miss the discovery step is handy.

Posted by Peter Wilkinson at

I like Tim Bray's suggestion on http://www.tbray.org/ongoing/When/200x/2003/07/03/HTTP-RSS .

For simplicity it makes sense to reuse the document layout we'll be using for necho as demonstrated by http://www.intertwingly.net/wiki/pie/EchoExample . So at the very least I would expect to reuse the elements (and attributes) used there.

So +1 to Tim's suggestion (and its REST alternatives), and -1 to anything that won't allow me to reuse parts of the structure of the EchoExample.

Posted by Isofarro at

Re: extensibility and content

Any SMTP/POP/IMAP server can take, forward and retrieve any
MIME message. In fact, any byte stream, but MIME makes the
analogy stronger by enforcing a RESTful architecture. The "envelope" is opened only when the message is examined by a Mail User Agent, if we except adding in transit information.

Here, if we are speaking about "dropping parts of the messages"
or "taking it all, even if we don't know how to use it", we are
running too fast. We should be thinking about transport, in REST terms, Transferring a Representation of State, and specify how to transfer Necho resources end to end.

Quoting REST:

REST components communicate by transferring a
representation of a resource in a format matching one of an
evolving set of standard data types, selected dynamically
based on the capabilities or desires of the recipient and
the nature of the resource.

Evolving, I think, is key here.

Posted by Santiago Gala at

anonymous - are you talking about the kind of things suggested by the ProfileMatrix? i.e. there is  common set of XML elements but different sets of them will be used in different circumstances - so an API delete POST would only need the postID element plus authentication elements (encrypted please!), a full post to the API would include everything from the syndication feed profile plus authentication elements.

I think this is a Very Good Idea (tm).

http://www.intertwingly.net/wiki/pie/ProfileMatrix

Posted by Danny at

SOAP in 1.after describes how using HTTP+XML today and allowing optional use of SOAP (specced now or later) supports Orthogonal Extensibility more successfully than suggesting requestors and providers blindly offer and silently ignore SOAP headers.

Posted by Ken MacLeod at

Necho Editing API

At last this part of the picture is getting some focus. I think it's the keystone of the whole project....... [more]

Trackback from Raw Blog

at

My vote would be a +1 for REST, a +.8 and +.8 for SOAP and XML-RPC. If we could support them, we should do it. If we could write up a good Necho to Datastructures mapping, we should put that into the spec of Necho so people using SOAP and XML-RPC can build on that. Those interfaces are bound to show up anyway, so better put them as sketch in the spec. But it should be something on the byline - not the primary goal, that should be a REST approach, as that looks more naturally to me in the Necho context (even though I have absolutely no preexisting stuff for Python and REST APIs, so I will have to write everything myself).

A big -1 to SOAP with inlined Necho content. This is a mode of SOAP call that almost no SOAP toolkit I used supports. It's a quite weird thing and makes everything overcomplicated. If you want to push stuff in it's native Necho XML rendering over the wire, use REST. That's what REST is there for.

SOAP and XML-RPC should be used at the "pass data structures" level.

Posted by Georg Bauer at

Oh, and I forgot to tell you, I added a python sample to the XML-RPC Samples page, so you can compare it to the other two already existing examples (and maybe see what we are talking about when we talk about data structures).

I always felt that SOAP or XML-RPC with passing data structures around is much more naturally with programmers that are already working on that level most of the time, while passing XML sources around is more natural to people more used to scripted stuff.

Actually almost every time I had to implement something where I was forced to pass XML sources around for communication, I ended with implementing serializer/deserializer modules to get some way to talk with the remote side that looked sane to me.

Posted by Georg Bauer at

I agree with Georg.

Here is my explanation (with a drawing! :-) ) of why using XML-RPC over HTTP POST makes sens.

Yes, some people want to pass around XML files, when some people want to pass around data -using XML secretly- (without having to deal with XML each time).

Posted by JY at

When I watch API people clashing with on-the-wire protocol people, I cannot avoid thinking on how right is Ben Hyde's small gods post. I left a comment there:

I don't get the point completely, unless the point is
something like "people will lock themselves into languages,
and most of them will never learn to unlock themselves using
protocols".

(While looking for the URL, I got this excellent post for free.)

Posted by Santiago Gala at

JY, Georg, and others: if you could do the same thing with straight-XML, post data and get data back in language structures, would that cover the same need?  Using the Python example:

data_out = http.post(newPosURI, xml(data_in))

Posted by Ken MacLeod at

Small thinko and typo, should be:

data_out = dict(http.post(newPostURI, xml(data_in)))

Posted by Ken MacLeod at

Ken,

Maybe i misunderstand but:

"do the same thing with straight-XML, post data and get data back in language structures"

and

"data_out = http.post(newPosURI, xml(data_in))
"

is what XML-RPC is all about.

So my question to your answer is yes, but i think that it would in fact lead to a xml-rpc variant.

It's why you always see Dave Winer complaining about REST i think. It's not that he doesn't like it, it's that it is frustrating to recode the serialization/deserialization everytime.

It's what the story is all about : some want to pass around data as XML, some want to pass around data using XML.

The advantage of the first approach is that you can do things with your XML file, like using XSLT, XPATH (but is it the purpose of the API?), and the advantage of the second approach is that the XML is hidden from the programmer view, you get instantly the data in your software. XML is just throwed away like a kleenex after it has been used as a data transport vehicule.

Posted by JY at

Big Deal, Redux

I have commented to a few people that Blogging is a Big Deal. Not, I hasten to add, because I think that anything more than a core of special people (special can have many meanings, but I like Halley's article...) will ever decide to participate in...

Excerpt from Webmink : the blog at

JY, I know what XML-RPC is about, I wrote the first publicly available implementation! :-)

I'm talking about an encode()/decode() that works with the same XML that others would be using "on the wire" with tools like XSLT, XML databases, etc.  The best of both worlds.

If you're a Python programmer, take a look at Aaron Swartz' xmltramp. For Perl programmers, there's XML::Simple and XML::Smart.

Those tools I just linked don't do all of it (encode, decode, and HTTP) but I know how they're written and they can easily support it.  These tools are just as simple , if not simpler, to write as an XML-RPC implementation.  Any language that works well with XML-RPC will work well with a tool like this.

Posted by Ken MacLeod at

+1 RESTian approach be it SOAP Doc/Lit or otherwise.

-infinity XML-RPC.

Posted by Christian Romney at

" I know what XML-RPC is about, I wrote the first publicly available implementation! :-)"

No offence, actually i'm just trying to see if my understanding is correct.

I think you sum it up very well with "I'm talking about an encode()/decode() that works with the same XML that others would be using "on the wire" with tools like XSLT, XML databases, etc.  The best of both worlds."

Some people really want the XML file (REST approach) to do different things with it, and for the others (XML-RPC approach) the XML file is just a temporary transport vehicle.

My concern is that a lot of the developers will, in the REST case, have to deserialize the XML file manually. They don't care about the XML file itself.

And using a tool like you describe would in fact require to implement such a tool in every environment. Why doing this when we already have this tool purpose in XML-RPC everywhere?

Actually i don't see how we can have the best of both worlds. A REST approach, with an XML-RPC proxy (your tool in fact) seems a way to go. But then i think that most people will use the proxy (or redevelop XML-RPC without knowing it if they use the REST API).

Thank's for this discussion, i'll be less stupid at the end of the day. :-)

Posted by JY at

One interesting point that I don't think has come up yet - it's obvious but may not be (errm) apparent.

If the same XML format is used throughout, then it should be possible to take the bulk of the XML message and store it unchanged to pass back as part of the syndicated feed. This could allow for a server-side Really Simple Implementation (RSI).

Posted by Danny at

Please guys, lets define the abstract structure of a message and let subgroups decide on the translation to explicit formats. It shouldnt be an option to mandate a transport, I think its outside our scope for the base necho. But as Tim Bray has pointed out, its useful to concretize in terms of a http profile so that we are grounded in specifying the additional things to the core echo document we need. As for exact http, xml-rpc and SOAP translations, let the market decide.

Posted by Rahul Dave at

Necho Update

I'm off to walk around favorite places today, but first an update on what was Echo and now looks to become Necho by default. I tried to catch up on the wiki, but a couple of days on the road has put me hopelessly out of touch on this project.... [more]

Trackback from Burningbird

at

To Ken: sure, that would give the same result. But it would be another reinvention of XML-RPC. Those who don't look at what is already there are bound to reimplement it ;-)

I think there are two options on how to support older interfaces like XML-RPC:

- provide a two-way-mapping from the XML representation (and so from the post structure) to datatypes and pass those structures as values in XML-RPC

- provide a simple and stupid interface where you pass the original post as a string or binary in it's XML format

The latter is but-ugly, but could actually work. The former is more natural for people used to passing around loads of nested structures, but might be offending to pure RESTian people ;-)

I don't think XML-RPC (or SOAP in it's standard RPC mode of communication) should be the base of the communication protocol, as the REST approach looks much simpler to me. But I do think that we should give a simple way for people to implement an API based on XML-RPC and SOAP, so they can make use of the buttload of available toolkits, without the need of reinventing the wheel.

Even though REST does look nice and simple in the spec, it is not the natural fit for all situations.

Posted by Georg Bauer at

+1 to anyone who suggests a document-centric process.

-1 to anyone who suggests a tight, pre-defined argument or structure-passing process.

Let's define the API once and extend capabilities by extending the documents shifted through it, not (re)define the API every time we want to move a new Echo-element's worth of information through it.

I guess that makes me -1 to XML-RPC and +1 to any document-centric RESTful/SOAP process.

Posted by Jeremy Gray at

+1 for REST.

I find it rather worrying that people are confusing transport protocols and transfer protocols.

(A hint: the transport protocol will without a doubt be TCP. It's the Internet, right?)

Posted by Arien at

Ken, "Those tools I just linked don't do all of it (encode, decode, and HTTP) but I know how they're written and they can easily support it.  These tools are just as simple , if not simpler, to write as an XML-RPC implementation.  Any language that works well with XML-RPC will work well with a tool like this."

A wrapper tool that provides an XML-RPC-like interface to the programmer for a document-literal wire protocol sounds like a good idea. Were you thinking this wrapper library would be generic, or specific to !echo? or perhaps a !echo specific wrapper around a generic tool? Ther's quite a bit of indirection going on here. I would worry that this would increase the difficulty of debugging client-server interactions.

JY, "My concern is that a lot of the developers will, in the REST case, have to deserialize the XML file manually. They don't care about the XML file itself."

And they'll be using regular expressions to do it (shudder).

"And using a tool like you describe would in fact require to implement such a tool in every environment. Why doing this when we already have this tool purpose in XML-RPC everywhere?"

Because the document-literal format is more amenable to direct manipulation by XML tools that the XML-RPC format?

For those who are advocating (or even 'don't care-ing') for multiple APIs, I'd like to point out that this will force anyone who wants to develop or deploy a client or a server for a situation where they don't control both ends of the wire (and this includes almost all developers in this space) to implement or deploy both/all APIs, significantly increasing the amount of work.

Please, whatever approach is selected, make sure there is only one API.

Posted by Michael Bernstein at

re: Michael Bernstein's "For those who are advocating (or even 'don't care-ing') for multiple APIs, I'd like to point out that this will force anyone who wants to develop or deploy a client or a server for a situation where they don't control both ends of the wire (and this includes almost all developers in this space) to implement or deploy both/all APIs, significantly increasing the amount of work.

Please, whatever approach is selected, make sure there is only one API."

+1. I'm now going to say REST OR SOAP (not REST and/or SOAP as I previously said), and in either case, I'm still voting for document-centric.

Posted by Jeremy Gray at

XML-RPC vs. REST

There is some discussion over wether to support XML-RPC interfaces for the new Necho API, or to just provide REST as protocol. In the following I try to discuss those two options. REST is - if you strip it of all it's hype - just passing XML ... [more]

Trackback from Python Desktop Server Weblog

at

Hey, guys: votes should go on the wiki.

Posted by Sam Ruby at

Sam, I'd love to cast my vote over on the Wiki, but unless I'm missing something the wiki needs more than a DontUseXmlRpc yes/no page. We could really use a new page on the wiki with a poll containing 8 choices:

- XML-RPC only
- REST only
- SOAP only
- XML-RPC and REST only
- XML-RPC and SOAP only
- REST and SOAP only
- XML-RPC, REST, and SOAP
- something else entirely

so that people can vote for an exclusive choice, not just what they want to see supported.

I considered setting up such a poll myself, but it would really be better coming from you.

Posted by Jeremy Gray at

Jeremy, IMHO this vote was ill conceived and ill timed... down to the name of the page.  Absent of context, this becomes merely a popularity contest, and attracts such gems as "SOAP is BigCo thinking".

Look at the RoadMap.  There is a reason this is the last step.  One thing I fully expect is that with [n]echo, there will be a significant usage of namespaces and extensibility.  Since the availability of XML-RPC toolkits is a crucial part of the argument for XML-RPC, I'd like see some prototypes and tests of interoperability and usability we can see using existing toolkits before we make decisions of this kind.

But that is just me.  If somebody feels compelled to vote now on such a subject, please do it on the wiki.

Posted by Sam Ruby at

Sam, I think you've misunderstood me. I never suggested that this issue needs to be decided now. Its WAY too early. That said, the following needs to be made clear:

1. My point was and is this: if the DontUseXmlRpc page is to continue to exist, it needs to present the kind of choices in my previous comment, not just a yes/no for DontUseXmlRpc.

2. If you don't want to see this discussed now (and I think you are quite likely correct) then the DontUseXmlRpc page needs to be shut down.

3. You fueled the discussion now by posting this very entry on your blog, so you would be well-served by considering your most recent comments in light of that fact.

Posted by Jeremy Gray at

George, I agree (if I understand correctly) I'm not against someone speccing extra interoperability.

Michael, xmltramp, XML::Simple, and XML::Smart are all generic.  I think .NET is too, but I'm not sure.

One thing I'm not sure some people are recognizing is that it's the same XML format to be used for all the bits: syndication, archival, and API.

The argument for using the same format for all the bits is that the same tools can be applied to all the bits.  For some, those tools will be serialization/deserialization, for others XSLT/XPath, for others XML databases.

If you look at this the other way, given the benefits people are ascribing to XML-RPC, one would expect people should be arguing that RSS should be in XML-RPC.

Posted by Ken MacLeod at

Sam, just re-read your last comment and am now interpreting it as a general commentary on the state of the DontUseXmlRpc discussion, as opposed to something directed at my comments.

That said, I think that #1 and #2 from my last comment are still valid.

We need people to focus on the right things at the right time, and now is not the time for DontUseXmlRpc, nor is it necessarily framed properly to generate good results regardless of timing.

As for #3, the first half of the sentence is valid IMHO, but the part following the comma can be taken with a grain of salt. :)

Posted by Jeremy Gray at

"If you look at this the other way, given the benefits people are ascribing to XML-RPC, one would expect people should be arguing that RSS should be in XML-RPC."

From my weblog post :

"Then you ask "eh, if so, why using RSS to syndicate data?! You have to decode the XML file and so on, so we should use an XML-RPC approach as you've just explained!".

Well, the thing is that in this case, you don't have the software on the left part of the drawing to do the data encoding in XML! Most RSS files are static files (so you can host them on any basic webserver), and yes you then have to decode the data from the RSS files."

Check the post for the context.

Posted by JY at

Sam Ruby says the vote on whether to drop XML-RPC was ill-conceived and ill-timed. Hmm. No matter. Developers chose to stay with XML-RPC by a wide margin. So now we look to Evan Williams to change his statement about dropping support of XML-RPC....

Excerpt from Scripting News at

JY,
I read your blog. Your entire argument relies on your arbitrary distinctions between "an XML file" and "data".

What you call an XML file is data to some application and your data can be represented as an XML file.

All the benefits you claim one can get from XML-RPC can be obtained using SOAP or RESTful APIs (XML + HTTP). The only difference is that XML-RPC is more hostile to using regular XML documents as payloads of the message than the RESTful or SOAPy alternatives.

Posted by Dare Obasanjo at

In my opinion, we're talking about defining an API, right? An API is a set of functions to communicate with the (blogging) software.

Indeed HTTP PUT gives you a simple API, but too simple IMHO (you can only PUT :-) )

XML-RPC gives you the ability to define verbs, functions (eh it's an API! :-) ) that can be called easily.

And note that XML-RPC uses an HTTP PUT!
But XML-RPC is an HTTP PUT on steroids that makes it easy to define more verbs :-)

Let's face it, the purpose of the API is not just moving an XML file around, it's really sending data to a remote software that will do cool things with it (storing it in a database, creating HTML versions, etc.. etc..)

Something we can agree on : you're a Nerd, so am I :-D

Posted by JY at

Sam writes:

Look at the RoadMap. There is a reason this is the last step.

But how could it be, Sam?! The design of Necho is in large part determined by the type of protocol it sits atop.

Posted by Arien at

Christian Romney

JY,
You can do much more than &quot;PUT&quot;. You can POST GET and DELETE.
In any case, the entire concept of REST is using a small number of verbs (all you really need, IMHO) and passing a representation of state (in this case an xml document whether in SOAP format or not) and having the app know what to do given the state and verb. I think you're short-changing REST considerably.

Message from Christian Romney at

Dare Obasanjo

JY
You don't get it. Maybe this post will help. http://www.kuro5hin.org/story/2003/7/3/64626/96017#restsoapxmlrpc

Message from Dare Obasanjo at

Arien: lets prototypes those designs.  "rough consensus and running code", and all that.

Posted by Sam Ruby at

I think we can use the general idea from the MetaWeblog API: apply a given set of rules to convert XML data to the XML-RPC model. The problem with the MetaWeblog API is that the XML data model isn't clear enough: If an element can occur more than once, the member in the struct has to contain an array. But it is not clear enough in RSS which items are allowed to occur more than once. Necho doesn't have this problem, because it has a schema.
It would be very easy to create an XSLT that converts a Necho document into an XML-RPC document. It would even be doable to create an XSLT that converts the Necho schema to a Necho-to-XML-RPC XSLT.

The bottomline: let's first create a RESTful API. The SOAP and XML-RPC APIs can then easily be derived from that.

Posted by Sjoerd Visscher at

Dare:

"What you call an XML file is data to some application and your data can be represented as an XML file."

- What you call an XML file is data to some application:

Yes, the REST approach really is pushing an XML file to the remote software.

- your data can be represented as an XML file :

Yes, that' what XML-RPC does for you for free (free as in "it's free and implementable in a few minutes so that i can get free time" :-) )

"All the benefits you claim one can get from XML-RPC can be obtained using SOAP or RESTful APIs (XML + HTTP)."

I put the SOAP case on the side (i have not spoken about it), i only see it as a complicated XML-RPC. Let's start simple ;-)

And no, i really think XML-RPC gives you an advantage that the RESTful API does not give you : the serialization/deserialization/type casting for free. I would really have to deal with XML parsing with the REST API. XML-RPC uses XML power without forcing the developer to deal with the power each time ;-P

Note : the "Something we can agree on : you're a Nerd, so am I :-D" message was not for you, you posted your last message while i was typing mine, i saw yours after posting mine :-)

Posted by JY at

JY,

Joe Gregorio have posted a document called "RFC for a REST based Echo editing API":

http://bitworking.org/rfc/echoapi.html

And opened a new section in the Echo wiki:

http://www.intertwingly.net/wiki/pie/RestEchoApi

Posted by Emmanuel at

Sam have also a note the "RFC for a REST based Echo editing API" here:

http://www.intertwingly.net/blog/1509.html

Posted by Emmanuel at

Sjoerd: that sounds like a real winner of an idea!  That's the kind of lateral thinking that I really like to see!

Thought of putting that on the wiki?  Or posting it on your blog?

Posted by Sam Ruby at

Bray: A Web Interface for Web Publishing.

Tim Bray has made [an entry on a Web interface for Web publishing]:http://www.tbray.org/ongoing/When/200x/2003/07/03/HTTP-RSS. I generally agree, and took a couple of quick... [more]

Trackback from tima thinking outloud.

at

Sam, let me try this another way.

Remember the discussion on HTML escaping? What would have been the point of that if people had decided not to use XML?

How can you design Necho if you don't know what it will be atop? Or are you looking for consensus on a combination of Necho design and underlying protocol?

I'm lost...

Posted by Arien at

Dare:

"JY, You don't get it".

I don't get what?! If the "it" was crystal clear there would be no point confronting ideas and you would already have 
the API defined.

It happens one of the possible solution is implemented and is working everyday for some times now, so give it the benefice of the doubt. thank's.

If the RESTian approach is really best in this present case, i would gladly like to be convinced. I'm trying hard to understand the various advantages/disadvantages. I'm not religious about it and would love a RESTian solution if it made the job easier.

"You don't get it" lets thing you have the one True knowledge. If it was so simple this 1507.html page would not have been reload so many times :-)

That being said, i've read your comments here :

http://www.kuro5hin.org/story/2003/7/3/64626/96017#restsoapxmlrpc

Here is the problem :

You say :

"No need for complex application frameworks or layers of indirection just HTTP + XML"

It happens the sofware will have to do something with this XML. It won't just store it as a text file. It will have to be processed to extract the data from it, then stored in databases (etc.. etc..).

XML-RPC does 95% of the job for you, while just passing the echo file via a PUT let you deal with the XML file creation/parsing.

So "just HTTP+XML" implies you're done with it. but no, you'll have to process the XML and it then does not look that simple a solution.

Posted by JY at

Arien: the latter.  Well put.  I don't believe that these things can be done in a vacuum.  Many things are intertwingled.  We may need to explore a plan A and a plan B, and see how the whole thing fits together in each.  Then decide.

I readily agree that making working assumptions in order to facilitate forward progress is often necessary.  Yes, for example, I am presuming XML at this point.  But that is just a presumption.  It could change.  In this case, I sincerely doubt it, but it could.

But to start a discussion with "DontUseXmlRpc" seems like an unfortunate way to approach such an emotional topic.

What matters much more to me than people's opinions on the subject are the proposals that are generated in the process.  A number of XML-RPC proposals were generated by this discussion.  And now a REST one.  Prior to this, a SOAP one.  Those are things we can evaluate.  Kick the tires.  See what works and what does not.

Posted by Sam Ruby at

XML-RPC, SOAP APIs derived from a RESTful API

This is an idea I had, which I posted on the XML-RPC, SOAP, and/or REST discussion. Sam Ruby thinks this is a "``"real winner of an idea"''", so I'll repeat it here:I think we can use the general idea from the MetaWeblog API: apply a given set of...

Excerpt from Sjoerd Visscher's weblog at

Sam Ruby says the vote on whether to drop XML-RPC was ill-conceived and ill-timed. Hmm. I wonder if that has anything to do with the fact that the developers chose to stay with XML-RPC by a wide margin. There's clearly no "community" here, Sam is...

Excerpt from Pete's Radio Weblog at

Burningbird burns one.....

Necho Update. I'm off to walk around favorite places today, but first an update on what was Echo and now looks to become Necho by default. I tried to catch up on the wiki, but a couple of days on the road has put me hopelessly out of touch on this...

Excerpt from Marc's Voice at

Sam, thank you for that.

I readily agree that making working assumptions in order to facilitate forward progress is often necessary.

I'm not sure if that helps or hurts making progress. I hope you are right, but I have my doubts. Let me explain using a couple of random examples of my current thinking (I envision a REST-y approach — for reasons I will not go into now, but this would work just as well given other preferences and assumptions):

Now, if I only mention the last item (or another one that builds on other assumptions and ideas), this would not necessarily make sense to others and I would have to explain how I got there. After which it might make less sense. ;-)

Somebody else might reply giving another "final destination", and would have to go back to square one to explain it to the rest of us. Repeat for lots of people with lots of opinions...

This makes communicating rather tricky (because you may or may not be makeing the saem assumptions and using the same terminology as somebody else) and could easily increase the signal-to-flame ratio.

Again, I hope I am wrong about that.

But to start a discussion with "DontUseXmlRpc" seems like an unfortunate way to approach such an emotional topic.

It is rather unfortunate that something like the choice of protocol is an emotional topic....

Posted by Arien at

REST?  I assume you intend to support REST as well?  I hope so.

For the record I would prefer to use SOAP but NewsMonster can support both just fine.

Kevin

Posted by Kevin Burton at

(not)Echo API

Simon Fell: There's a post on Sams blog about whether to use xml-rpc, soap and/or rest for the (not)echo weblogging API. And a raging discussion on the Wiki as well. Having implemented the Blogger API, Metaweblog API and RESTLog in the past, I'm all...

Excerpt from Jeff's Radio Weblog at

Burningbird burns one.....

  Burningbird burns one..... Burningbird burns one...... Necho Update. I'm off to walk around favorite places today, but first an update on what was Echo and now looks to become Necho by default. I tried to catch up on the wiki, but a couple of...

Excerpt from Audioblog/Mobileblogging News at

Quick Links - 2003 07 03

Last update: 03/07/03; 14:15:45 EDT Scripting, Blogging, Softwares... Georg Bauer: XML-RPC vs. REST : There is some discussion over wether to support XML-RPC interfaces for the new Necho API, or to just provide REST as protocol. In the following I...

Excerpt from blog.scriptdigital.com at

Sam Ruby says the vote on...

Sam Ruby says the vote on whether to drop XML-RPC was ill-conceived and ill-timed. Hmm. No matter. Developers chose to stay with XML-RPC by a wide margin. So now we look to Evan Williams to change his statement about dropping support of XML-RPC....

Excerpt from A Father and his two girls at

REST and RPC

Posted by Ken MacLeod at

A Web Interface for Web Publishing: Today Sam Ruby launched a discussion of API options for weblogs, or more generally for Episodic Web Publishing, or even more generally for the Writeable Web. This is in conjunction with the ongoing effort to...

Excerpt from André Venter: Dev at

XML-RPC, SOAP, and/or REST. Dave Winer: Here's the Wiki page where people are deciding whether to use XML-RPC and/or SOAP. You can express your opinion if you like. That's how it works. Excellent! Now lets see if we can have a respectful dialog on...

Excerpt from André Venter: Dev at

+1 on a pure POST API. Its all about documents guys. Data flowing, transforming, RESTing. For those who wish to think in terms of APIs, lets provide API's on top but keep the core "entry point", really, really simple - HTTP POST with a document payload (not an encoding of an API call - a document).

Posted by Sean McGrath at

XML's Various Personalities

I used to see two completely distinct roles for XML: a way of marking up text (ala DocBook) or a data-description method (the way XML-RPC uses XML). Now, these are obviously valid ways of using XML, but if this constitues your complete paradigm (as... [more]

Trackback from OpenWeblog.info

at

Nobody's out to harm you, Dave. They just want to play.

I was tempted to use the flamebait title The internet interprets Dave Winer as damage - and routes around him...... [more]

Trackback from Notes from Classy's Kitchen

at

Adaptability = Extensibility + Intermediaries (Federation) + Interoperability?

I've been thinking a lot about SOA (Service-Oriented Architecture) these days, and to me, the essence of SOA is interoperability (aka integration). One might say that interoperability is simplly a network-centric way of thinking about modularity–decomposing complex systems into a network of simpler subsystems (modules).

When thinking about modular systems, one can focus on the modules and how the designer has factored the overall system to optimize adaptability (minimize coupling and maximize coherence) within the modules (modular adaptability). Or one can focus on perhaps the most important subsystem ("module"?) in the decomposition: the subsystem that enables the interaction among the modules. A great book with keen insights in general systems thinking, Fault Tolerance: Principles and Practices, refers to this interaction-enabling module as the design of the system.

So for example, if integrated circuits (ICs) are the "modules," then the circuit board that connects them is the "design." Continuing the analogy, there are many ways to design a circuit board–from soldering onto copper traces to a pluggable breadboard. But note that one can view the design as embedded not only in the circuit board, but also in the connectors embedded in the chips themselves. (Another way of putting this is that the design is embedded in both the connectors among the modules and the interfaces exposed by the modules.) A core issue of adaptability in designing a circuit board is designing one that can not only enable hot swapping of ICs (modular adaptability), but one that can also enable ICs with very different connectors to still interact, e.g., 5-volt ICs interoperating with 12-volt ICs, or electrical ICs interoperating with optical ICs.

This is what SOA is all about. As the electrical to optical example shows, however, to achieve interoperability between such different connection types requires a design that abstracts away all physical details and enables interoperability purely in terms of abstract (i.e. informational) identifiers, formats, and protocols (IFaPs). When a physical component has been abstracted to such a degree, it is appropriate to think of it as a service (aka process, abstract state machine) instead of an object (thing, physical machine). Of course, to achieve this level of abstraction (e.g., spanning optical and electrical designs) requires that the abstract design be based on intermediaries between the concrete designs. Such an abstract circuit board design would be a federated design.

Now a data communications network, like a circuit board, is a design that connects a set of modules to form a system. (Actually, both the data network and the circuit boards are both "networks" in the general sense of the term. Perhaps design == [is equivalent to] network [connectors, intermediaries, and interfaces].) As with optical and electrical circuit boards, different networks have different physical characteristics. (There are in fact optical and electrical networks.) Thus, the core issue of adaptability in the network context is interoperating across two different types of networks so that modules on each network can be composed or combined to form a single system. This of course entails abstracting away from network specific IFaPs to abstract IFaPs that can be bound to any concrete IFaPs. (SCSI in fact does this across the optical [fibre channel] and electric [buses] networks that make up a SAN.)

The Internet did this, didn't it? So aren't we done? Well, yes, but there is no easy way to evolve the Internet IFaPs themselves. We've been waiting for a decade to evolve from IPv4 to IPv6. So in designing a network abstraction to overlay the Internet, we should not repeat the same mistake. We must design it to enable the generation of a wide variety of abstract IFaPs; hence the need for extensible formats (SOAP envelope) and extensible Message Exchange Patterns (protocols). (I'm not sure whether URIs are extensible enough identifiers. I have to look into XNS/XRI further.)

So: The adaptability of a design can be broken down into two distinct types of adaptability. First, the degree to which the design enables the modules to evolve/adapt internally, e.g., to enable one module to be replaced by a functional equivalent with superior performance/quality/price. Second, the degree to which the design itself can evolve/adapt.

I think HTTP and REST make the same mistake as IPv4. Although REST enables the evolution of the resources (modules) it interconnects, the REST IFaPs are not themselves designed to evolve to the same degree as the SOAP IFaPs. For example, SOAPv1.2 is adaptable enough to serve as the design of the IPC (Interprocess Call) of an operating system. REST designs, because they are currently so embedded in the concrete protocols of the Web (i.e., HTTP) cannot be applied in this way.

Posted by Nick Gall at

(not)Echo API

<a href="http://www.pocketsoap.com/weblog/2003/07/1321.html" title="(not)Echo API">Simon Fell</a>: There's a post on Sams blog about whether to use xml-rpc, soap and/or rest for... [more]

Trackback from Jeff's Radio Weblog

at

Sam Ruby: XML-RPC, SOAP, and/or REST

[link]...

Excerpt from del.icio.us/tdmsilvino at

Sam Ruby: XML-RPC, SOAP, and/or REST

[link]...

Excerpt from Delicious/maane at

Add your comment