What is JSON, JSON-RPC and JSON-RPC-Java?

Michael Clark writes "Seen those funky remote scripting techniques employed by Orkut, Gmail and Google Suggests that avoid that oh so 80's page reloading (think IBM 3270 only slower). A fledgling standard is developing to allow this new breed of fast and highly dynamic web applications to flourish. JSON (JavaScript Object Notation) is a lightweight data-interchange format with language bindings for C, C++, C#, Java, JavaScript, Perl, TCL and others. It is derived from JavaScript and it has similar expresive capabilities to XML. Perfect for the web as doesn't suffer from XML's bloat and is custom made for our defacto browser language. JSON-RPC is a simple remote procedure call protocol similar to XML-RPC although it uses the lightweight JSON format instead of XML (so it is much faster). The XMLHttpRequest object (or MSXML ActiveX in the case of Internet Explorer) is used in the browser to call remote methods on the server without the need for reloading the page. JSON-RPC-Java is a Java implementation of the JSON-RPC protocol. JSON-RPC-Java combines these all together to create an amazingly and simple way of developing these highly interactive type of enterprise java applications with JavaScript DHTML web front-ends. " Click below to read more about it. "Now is the turning point. Forget that horid wait while 100K of HTML downloads when the application just wanted to update one field on the page. The XMLHttpRequest object has made it's way into all the main browsers with it's recent introduction into Opera and Konqueror (sans the Konqueror bug). This new form of web development now works on Internet Explorer 5, 5.5, 6, Mozilla, Firefox, Safari 1.2, Opera 8 Beta and Konqueror 3.3 (with a much needed patch). Appeal to Konqueror users - please log into the KDE bugzilla and vote on this bug so you to can experience this wonderful thing. More details here: http://oss.metaparadigm.com/jsonrpc/ "

Comments

Pros and cons?

[Sierpinski]

Two major issues that come to mind with this type of technology:

1) How easy is it to learn for the average programmer

2) What kind of security precautions can we expect to see?

Otherwise it sounds like a great technology to use for web developers who wish to have dynamic content on their sites.

Re:Pros and cons?

[metaparadigm]

A1. The idea is to make it transparent to the programmer. You can practically just call a Java method from your JavaScript web application. one line of code is required to export or allow access to a server-side object.

A2. Yes, security is an interesting topic. The Java implementation refered to works on a deny all by default - allow specific objects to specific clients. It does require the programmer to think about what methods they are exposing. I have been using it over HTTPS with selective objects exported to authorized clients (using the existing JAAS Java authorization and Authentication framework), so I believe it can be used in a very secure way.

Re:Pros and cons?

[Jetifi]

Well, JSON is a subset of JavaScript object notation, so people who know JavaScript already know this. It's basically a way of transfering structured data between browser and server that is less verbose than XML, and can be eval()ed straight into javacript itself.

Of course, any server receiving this stuff via POST should do the same validity checks it does on anything else it gets from the wire. On the client, IIRC you can only use XMLHttpRequest with the server the document originated from, and neither should you be able to execute script across domains, even within iframes, so the existing browser security model should be sufficient to prevent additional security problems, bugs and exploits notwithstanding...

Click below to read more about it.

[Threni]

With all that stuff going on it's a wonder it didn't click itself!

Perfect for the web? I don't think so

[Anonymous Cowherd X]

Example in JSON:

{"menu": {
"id": "file",
"value": "File:",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}]}}}

The same thing in XML:

<menu id="file" value="File" >
<popup>
<menuitem value="New" onclick="CreateNewDoc()" />
<menuitem value="Open" onclick="OpenDoc()" />
<menuitem value="Close" onclick="CloseDoc()" />
</popup>
</menu>

Perfect for the web as doesn't suffer from XML's bloat and is custom made for our defacto browser language.

Take a look at those examples and try to explain how is JSON free from bloat when in fact it is even more bloated and slightly more difficult to read and write by humans? It's just another notation with no obvious advantages.

Re:Perfect for the web? I don't think so

[metaparadigm]

Yes, although this is an XML DTD discussion. Most DTDs including the XML-RPC and SOAP DTDs don't encode using attribute values but instead using child elements with character data (apparently this is the XML best practice). Much Much bigger.

Also, the JSON takes one line of code to parse and access natively in our defacto web browser language 'JavaScript'.

The second requires a bloated JavaScript XML parser (as this is not built in to many browsers) and CPU intensive processing and a cumbersome API to get the data out. Also try doing 100 RPC calls a second with SOAP in a browser (this can be done with JSON-RPC on a local network - 10ms round trip on simple methods).

Re:I have only one point to make.

[MancDiceman]

Imagine yourself in 5 years time. The web browser has all this stuff on it which means it is as good an interface as any other GUI widget stack. Firefox or Safari or IE or whatever effectively is the window manager with tabbed browsing and links to your favourite 'applications'.

The interface is fluid, keyboard shortcuts working fine and everything is as responsive as it is right now in your current desktop. Your applications are used over the web - you don't have to worry about software upgrades or fixing your parent's computer after some installation as everything is done by your ISP.

Can you see that future? What is stopping it from happening?

You're right, the browser is a crap interface. If you actually understood the technology being described, you would realise that it is an improvement to the interface to make all those things happen.

The browser is a bad interface right now. JSON helps to make it a more suitable interface. Go figure.

Re:I have only one point to make.

[ceeam]

IE besides - "Web app" is a darn appropriate interface for a lot of things and definitely the single most widely spread and portable one. The inability to request a "callback" value from the server from the JS code is a huge PITA if you've ever tried programming those.

Re:I have only one point to make.

[Malc]

Web interfaces have two massive advantages: no need to install anything. They also work just about anywhere.

You're right: a web page for a complicated will rarely match the UI of a dedicated application. Take Outlook's Web Access UI: it's pretty amazing, especially if you're using IE. It can be used almost anywhere without having the latest version of Office installed. It's still damned clunky compared with real Outlook, but sometimes it's better than nothing.

Re:O...k.....

[rdc_uk]

"So now people can't bookmark specific products"

Fair comment, though I can think of places where similar features are desirable -> changing product images is a better usage.

"Useful from a commercial point of view. Really rather distracting from a visitor point of view. If I can't block it, I'm likely to find another vendor."

Good luck; sites designed to sell tend to ADVERTISE their wares. You seem to be thinking 3-second rotation; I'm thinking more 1-minute rotation of current "specials". Put bluntly; I have clients that will pay me to do this if its possible.

"This sounds practical, but at some stage you need to send the user to a new page anyway, and you can calculate new totals without having to make server calls."

1; I don't want the mechanism for calculations at the client side, so the calculation would require a reload, therefore this will make the page more responsive; i.e. better. The reason for non-client side? First: javascript is a shit language for anything other than DOM manipulation. Second: clients don't want their business logic exposed in javascript. Third: we don't want to download all the data required for those calculations to the client (prices in a code-manipulatable form should NEVER get to the client side, or be sent via post/get, prices just get displayed to the client, not manipulated by them)

Think about a checkout that calculates shipping costs globally; you need the location from the client. Depending on location the methods available for shipping will change. Depending on weight of goods (changes with quantity change) and location, the costs for each method change.

Thats a LOT of information to download to the client's machine to make the totals update without a server-call. Its also a ton of information (including prices) that I don't want the client side to have access to, and that I don't want javascript responsible for calculations on.

If I can pull down just the new value, rather than the whole page -> better!

"Ummm... why would you want an RSS new ticker on a webpage in the first place?"

Again; clients will pay for it. Just because YOU don't want it (or, in fact, that my client's clients don't want it), doesn't mean it has no value.

"Yes, lets just create something with no practical advantages over Flash/Iframe, but which requires a more recent browser to access."

There are plenty of advantages to not using flash. (reduce number of languages required to display 1 page and reduce number of external plugins required to display 1 page to name just 2 advantages)

Iframes are never a good idea.

And did you read the list of supported browsers? Only notable omission in the real world was safari...
2;