

Ask HN: JSON or XML, questions about an idea ? - jacquesm

For a brand new API, which would you choose and why ?<p>I'm busy building a small social network, it will have an API as its main component, in fact most of the site itself will be built using the API.<p>If you have experience with both these techniques which do you think is the best way to go.<p>Eventually the API will be made public, power users will be able to write plug-ins for the site in javascript using a 'development' field in their profiles, these will be loaded after the 'default' code for the site loads and should enable the developers to modify the way the site works as much as possible.<p>Once a user has tested a plug in on their own account and has verified that it works properly they can submit it for general availability after an inspection to make sure that they are not doing anything nasty.<p>The resulting plug-in is then 'versioned' (cloned and given unique id) and made available to other users.<p>All the code will be served up by our server, so unlike facebook or other heavyweight APIs there will be no external servers involved (for now at least, who knows where this will lead...).<p>Has something like this been done already ?<p>Thanks for any and all information :)
======
TomOfTTB
My first question would be "what are you writing this social network in?"
Because I think every mainstream language in existence has free libraries to
create both XML and JSON output (Javascript is made for it, .Net has WCF,
there are several Gems for Ruby, php has _encode, etc...). So implementing
both should just be a matter of passing the values to the appropriate function
and reaping the benefits of already available libraries.

That in mind I'd say both. If for some reason you insist on choosing I'd
probably say JSON. XML's only real advantage over JSON, imho, is it's human
readability. That makes it great for stuff like configuration files. But for
machine to machine communication JSON is faster and less prone to conversion
errors. Plus it's easier to accept JSON in Javascript which you defined as
your target audience.

~~~
jacquesm
It's strictly machine-to-machine, basically this is a way of extending the
functionality of a website without having code server side, all the extension
code runs on the browser of the end-user and talks to the server using the
API.

The server side code for the project is going to be in PHP.

Think of it as HN on steroids, custom filtering and alternative user
interfaces, tweaks and so on by adding chunks of javascript to the site,
either just for yourself or if you think your stuff deserves a greater
audience as a switchable plug in for others. If something is very well thought
out we might make it default to 'on'.

Greasemonkey allows you to do some of this for a single user, but you normally
wouldn't have access to the 'raw' data that builds up a site, in this case you
would, all the rendering comes from the javascript. Another part of the
configurables is custom stylesheets.

The general idea is that you can completely overhaul the front end of the site
from a plug-in on the assumption that more than one person will want to make
those changes we make those changes available to the rest of the users.

I got the idea a while ago while browsing HN, it's one of the things that made
me wonder how far you can push customization of a website and my conclusion is
very far if you are willing to give up control.

So the only criteria I would attach to public distribution of an extension
would be that the extension is not malicious in intent. Beyond that it is
'anything goes'.

A 'hackable' social network. Very simple in basis but extremely extensible.

------
jasoncartwright
XML/JSON: Answer is both. If you've built it well then you can just switch a
template.

Your plugin system sounds a bit like AppEngine.

------
thelonecabbage
JSON if you need SPEED at the client or server ends. If speed isn't a major
factor than XML may win out, depending on the complexity of the data your
sending back. XML in large, hierarchies is going to be easier to read.

~~~
metachris
i agree. JSON for "simple" data structures if you want to save bandwith, XML
if you want to have more complicate structured documents with markup.

~~~
jacquesm
That's a tough one. Ideally the javascript would render the page so that the
absolute minimum would be transmitted across the line, basically just the raw
data once per page, the javascript would stay cached on the clients machine.

But sending markup along would make the whole thing considerably easy to
implement, I think (but this could be just a wrong gut feeling, I'll have to
figure that one out).

------
tmikew
I prefer JSON. Though I do agree with the other comments that xml is more
readable if the structure is big, and that one can easily (and perhaps should)
do both.

In practice I have noticed that where I work we tend to have complex data
structures but not very deeply nested ones. We wrote a simple find function
that recursively traverses the JSON structure looking for keys. Not anything
nearly as powerful as XPath but sufficient.

It tends to be highly useful in my experience to create a list of objects. For
example instead of a list of phone numbers a list of phone number objects. One
may then easily add attributes to the phone number. Primary, cell phone, home
phone etc. This tends to be highly flexible in that attributes may be later
added that were not at all considered up front.

Of course all of this can be done with xml as well. JSON just _seems_ more
convenient. If I add an attribute in Javascript or Python I can just use it
and get on with it. No messing with my SaxParser or building up some new
XPath. Again I am not bashing xml at all, this is just my take.

In practice we use JSON exclusively in the core services for input and output.
When we need to use xml we convert it to JSON and then back to XML as a
filtering process rather than fool around with our core services. This adds
overhead but keeps us flexible and loosely coupled.

------
pauljonas
JSON.

It makes for a significantly smaller payload (especially important in that in
most cases, you're transmitting a great number of smaller chunks) and I don't
buy the readability argument — especially when it's almost a no-brainer to
employ a function to display to "pretty" indent JSON represenstation — print_r
in PHP, pp in ruby, etc.…)

I believe just about every language used in web development includes a library
for shuffling JSON in and out of native data structures.

------
hboon
JSON first. XML when people ask for it and when you have no more excuse to
delay it. It is so much easier to play with JSON, or to pick a particular
value. Most languages (with a library built-in or not), lets you manipulate
the result as a combination of dictionary/hashmap and array/list. It is SO
easy.

------
jimfl
And advantage of XML is the ability to easily get substructures out of the
data using XPath, and/or use XSLT to transform the XML directly to XHTML. So
if you expect API users to be doing any filtering of the requested data on the
fly at the client side, XML may be preferred.

Another rule of thumb is that the deeper the nesting of complex data
structures, the easier XML will be to manipulte. With XPath I can quickly get
a list of all the foo/bar/baz where haha=true, whereas with JSON I would have
to have three nested loops to extract that data.

------
amutap
I would suggest provide support for both. As it has been mentioned, there are
libraries that you can use to generate either of these. Tumblr is the first
that came to my mind - it provides support for both.

Give developers freedom to choose either of them...

------
nreece
XML - because it is easily parsable, both client-side and server-side.

