openstack team mailing list archive

[Mark Nottingham <mnot@xxxxxxxx>]

On 13/04/2012, at 11:29 AM, Jorge Williams wrote:
> 
> There are a lot more clients than servers.  You have to weigh the cost of lowering barriers for those clients at the server side vs the cost of getting those client to successfully integrate with the system.  This is typically the a argument I make against SOAP and towards REST.  In static language circles creating a SOAP service is really, really  easy…

As long as the server and client are using the same tools, yes. SOAP doesn't provide any interoperability, it's just an envelope for a proprietary messaging protocol. Background: <http://www.mnot.net/blog/2006/05/10/vendors>

But I digress...


> but using soap typically introduces  high barriers to dynamic language folks.  Making the move from SOAP to REST definitely introduces some complexity on the dev side of the service in dev cycles, but you have to compare this cost against the cost that's saved on the client side and multiply that by the number of clients that benefit. 
> 
> Having said that,  I understand the cost of supporting a different media type is not insignificant, but it's also not rocket science. I reckon that the sate of XML support today may have to do more with the fact that our dev community doesn't see much value in XML, than in does with what it will actually takes to get it right....and like I said before, I can understand that perspective. 

OK, we're going to have to disagree here. It's not that just "our dev community" isn't seeing much value in XML, it's a good portion of the world. The question here is how far we bend over to cater to those who are using these tools, and how we go about it. I'm suggesting that doing it in the protocol, rather than with tools, is buying us more long-term trouble than it's solving for them.

In particular, if people are actually using these tools to do data binding, it's going to lead them to place dependencies upon the structure of our interfaces, and unless the scheme is constructed *exactly* right, we'll get lots of bug reports in the future when these tools base their "contracts" on their interpretation of a Schema that got published on the Web site at some point in the past.

However, I question whether it's even being used in this fashion. Looking at our docs for Nova <http://docs.openstack.org/api/openstack-compute/2/content/>, the schema isn't locatable, and the XML Namespace <http://docs.openstack.org/compute/api/v1.1> is a 404. How are they finding the schema, and how is it getting into these tools?


> It messes up some of the syntactic sugar that folks are used to using:
> 
> server.name    vs   server["foo:name"]  

If you use colons, sure, but let's not try to reinvent Namespaces in XML in JSON.


>> Sure. The question I'd ask, then, is it worth making our APIs seriously more complex, hard to develop, understand, maintain, test, document, etc. in the meantime, just to allow static language users to have their IDEs help them. Something that the dynamic folks have gotten pretty used to living without.
> 
> Asking static language folks to just get used to not having compile time checks is silly. That said, I don't want to turn this into a static vs dynamic language debate.  I advocate just as hard for good JSON support when I'm dealing with static language folks....go talk to the atlas guys.
> 
> Again, I'm generally agreeing with what your article is saying.  If we had great/nontrivial static language binding support...that's extensible and flexible enough to remove the need to go down to the HTTP level, then there wouldn't be a need for this debate.


Let's get there, then!

We won't have them tomorrow, so what I think we need to think very carefully about is whether offering this audience XML at this point in time is doing more harm than good, both in terms of opportunity cost and in terms of causing problems down the road.

I'm not talking about *removing* XML from the current APIs that ship it, BTW; at most I'd like to see us:

1. Not require XML for new APIs, and
2. Talk about deprecating XML support in current ones (i.e., still support it, but de-emphasise it in documentation, don't expend new effort on it), and
3. Put some considered caveats around our current use of WADL and XML Schema.

Cheers,


--
Mark Nottingham
http://www.mnot.net/