DISQUS

aaronsw · 1 year ago

JSON JSON JSON JSON.

dave · 1 year ago

IF YOU DO ALL YOUR CODING IN JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT.

aaronsw · 1 year ago

JSON libraries are now available for more languages than XML-RPC libraries; check out http://json.org/

dave · 1 year ago

I'll think about switching when someone recodes all my apps that use XML and also reprogram my brain.

jonknee · 1 year ago

But you were just complaining that REST lacks a standard data format (which is really missing the point). JSON fits that bill perfectly, it's easily parsed by about any programming language. It's lighter and faster than XML too, which is a big plus for client-side JavaScript stuff.

Maybe you should change your stance that your problem isn't a lack of a compatible standard, it's that the compatible standard isn't the XML format you made up for XML-RPC.

AndrewBurton · 1 year ago

Someone should split the difference and write a JSON encoder/decoder for Frontier.

dave · 1 year ago

Good thinking!

RESTFan · 1 year ago

REST does not dictate a particular payload format, which is a good thing. In this way a REST API can provide several different playload formats including XML, JSON, etc.

James Newton · 1 year ago

FriendFeed is an example of a service that provides choice of payload formats using a REST API: http://code.google.com/p/friendfeed-api/wiki/Ap...

lmorchard · 1 year ago

IMO, it's a good thing if an API *picks* a format and sticks with it. It's a seemingly nice feature for end-user developers to have choices in formats — but it can be not-so-nice for the provider to keep all the code forks maintained, and preserve parity between them all. And, eventually, that's not-so-nice for end-user developers who have to figure out which part of the API does what with which format and choose the libraries they need to use.

If you can get away with an all-JSON API with some nice JSONP-style callbacks for browser mashups, great. But, try to use JSON for the PUT and POST writes to stay consistent.

Or, stick with XML throughout, with maybe some exceptions for JSONP mashup feeds.

lemon obrien · 1 year ago

i used you XML-RPC a long time ago 99/2000? I never went SOAP cause your XML-RPC was just s much easier to do; figure out; maintain; etc.

DaveWoodbury · 1 year ago

I agree with Dave that XML-RPC in many ways hits the sweet spot for distributed programming.

There are HTTP libraries and XML parsers for every language and platform.

That's all XML-RPC needs.

But, XML-RPC is merely an artifact for software anthropologists to pick up and turn over to try to understand where it came from and what it was used for, because, for the most part, XML-RPC is no longer a mainstream solution. I struggle to find current information about how to do XML-RPC and current libraries. Entropy seems to be doing its job with XML-RPC. (Even Dave's XML-RPC page is in need of some attention to fix broken links...)

I don't think SOAP is quite as complicated as Dave says it is. It can be scaled to be almost as simple as XML-RPC and almost if not more capable than CORBA.

Tooling for SOAP is in great shape. (libraries, development tools, etc...)

REST is proclaimed to be a style, and so there are ambiguities that are left to us to address. In a sense, XML-RPC is a RESTFul implementation due to the way it plays over HTTP.

dave · 1 year ago

Tell Dare et al to include it as a "historic artifact" in their recitals of How We Got Here.

Tom · 1 year ago

Not really: XML-RPC does not take advantage of HTTP, especially not of the stateless caching feature of GET, not of the Safe feature of GET, not of the idempotence of PUT, etc. Frankly, I don't miss PUT & DELETE, but only using POST but not GET for safe operation is the thing, which keeps me away from XML-RPC.

rogerben · 1 year ago

Well, you *could* use XML-RPC as a payload in a RESTful app... all you'd really need to do is treat the method/fail elements as vestigial organs and use HTTP verbs and URIs appropriately. But as others have pointed out, once you're doing that, why not just use JSON and get the bennies of broader client support?

Dare Obasanjo · 1 year ago

I see someone has beaten me to the punch and pointed out that if you build a RESTful service with JSON instead of XML payloads you get all of your touted benefits of XML-RPC and all the benefits of conforming to the Web's architecture. Thus having your lunch and eating it too. :)

dave · 1 year ago

Well maybe so -- but we have tons of XML apps and as I said elsewhere in this thread unless that all magically converts itself, we're going to be using XML for a long time (and that's a good thing, not a bad thing).

And of course this completely side-steps the point of my post. Why do you leave XML-RPC out of your history? Why don't you just update your post, because it's wrong, and let's move on.

Noah Slater · 1 year ago

He wasn't giving a history lesson of RPC systems so how is his post wrong just because he didn't draw some redunant analogy to some other RPS technology you happen to have a vested interest in promoting?

Leo Horie · 1 year ago

I thought the point of the "being RESTful" phylosophy was DRY, not to be the next-big-framework.
>> a standard method of serializing structs, lists and scalar types.
Doesn't plain old XML do just that? You don't need to use JSON to be "RESTful", afaik.

jobol · 1 year ago

An argument often put forward against using XML for serializing data is the overhead caused by the verbosity of the language. As a document description language however it is well suited, imho. Anyway, XML-RPC featured in this week's highlights :-).