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

O...k.....

[Anonymous Coward]

*finishes reading summary*

ok... so... huh?

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

[rdc_uk]

So...

repopulate your product page for a new product WITHOUT reloading the whole page.

Put a timer in, and have rotating feature products WITHOUT reloading the whole page on a timer.

Update your totals in your chckout / shopping cart WITHOUT reloading the whole page.

Write an RSS news ticker in html rather than flash...

Basically anything that you might have used flash or an IFrame for, you could do with this, javascript and a DIV tag... Pretty important news (if you write commercial websites)

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

[dorward]

repopulate your product page for a new product WITHOUT reloading the whole page.

So now people can't bookmark specific products

Put a timer in, and have rotating feature products WITHOUT reloading the whole page on a timer.

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.

Update your totals in your chckout / shopping cart WITHOUT reloading the whole page.

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 - so you might as well leave telling the server about it until they go to the next stage of the checkout process.

Write an RSS news ticker in html rather than flash...

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

Basically anything that you might have used flash or an IFrame for, you could do with this, javascript and a DIV tag... Pretty important news (if you write commercial websites)

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

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;

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

[Zphbeeblbrox]

Uhmmm... Actually I've been doing this for a while now using iframes and javascript. It's not that hard and also avoids the xml bloat. This just gives a "standard" api to use when doing it. It still uses Iframes you just don't have to create them yourself. Most people who have been doing this already have a set of custom tools to help them do it. The functionality has been there for a while. This will help boost its use though and for that I'm grateful. Gmail makes excellent use of it in their UI making it hugely more useable than most other webmail clients. More people need to be recognizing the, already present, power for dynamic applications in the web.

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

[ryepup]

So would you rather download <1K to get the new cost in your cart, or download 100K of HTML and images and have the screen flash to get the new cost? As a web host, would you rather serve 1K or 100K?

The other side is responsiveness of the application. A lot of places use the web for more than shopping carts, and this is the sort of technique that makes a web app seem multithreaded. Don't you like the multithreaded applications you use? Wouldn't it be cool to offer similar speed easily via a web browser? Right now my main option is to have a lengthy process performed in a pop-up window, or post back and start a new thread on the server, which both involve more work than it should.

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

[CurlyG]

Weren't Java applets designed to do all the things you mentioned?

If applets failed, what reason is there to believe this technology will fare an better?

Because client-side embedded Java applets are a drastically impractical, inconvenient, bloated and slow way to do trivial tasks like this. (NOTE: not a Java troll - it's an awesome language for server-side and standalone client-side apps).

OTOH, ECMAScript/Javascript is built into every browser produced in (at least) the last 5 years, is fast, has zero startup overhead, and is widely understood by every web developer on the planet.

I rarely see Java applets anymore, for the above reasons. I do, however, see many more Flash apps, which have their own set of problems, including that they require yet another set of 3rd-party software to be installed and configured on the client's computer, rendering it undesirable from the point of view of most shopping and ecommerce sites.

This is an elegant solution to something developers have been forced to use ugly workarounds to achieve for years.

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!

Fix HTML instead?

[Spiked_Three]

I've had to resort to all sorts of tricks to avoid postbacks in my current (aspx) development efforts. First we used a thrid party soap-xml RPC like this thing. Then we switched to an IFrame for the postback portion. Then I noticed that MS is including their own new and improved soap-xml RPC thing in .Net 2. Now I read about this.
Seems it is a problem a lot of people need/want to solve - but to be honest, I am tired of having so many different solutions to a problem I should not have to begin with. Isn't there something that can be done with the HTML standard to elliminate the need? Life would be so much better down that path.

Re:Fix HTML instead?

[TheRaven64]

I don't think HTML is to blame so much as HTTP. The integration of something like XMPP into the browser would be a huge improvement, since it would allow arbitrary XML to be pushed to the client without the need for polling (which is ugly, and no less ugly if it's done in the background without the need for full page refreshes.

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:I have only one point to make.

[hey!]

Well, I think you're missing the point.

These applications areng going to use a browser interface. The are going to use the browser as a platform on which non-browserish presentation layers can be constructed.

This is exactly the future that caused Microsoft to go bezerk over Netscape all those years ago.

Pushlets

[tezza]

http://www.pushlets.com

This is a server side push framework based on the same idea. It preceded GMail et alia.

Re:I have only one point to make.

[uradu]

> 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.

No, a real improvement to the interface would be to move away from any technologies that mix (D)HTML and executable code. It's a recipe for unmaintainability and for driving self-respecting desktop developers to despair. True advances in distributed apps are approaches such as Mozilla's XUL. Alas, they're a step away from the quasi-declarative "programming" of (D)HTML back to the procedural programming of C and its descendants, not something artsy web "developers" like to hear.

Re:I dare to disagree.

[arkanes]

Eh. Not really. Auto-updating isn't especially difficult, especially in the close environments most web applications are written for. Java Web Start, for example, is a cinch. It's not too hard to roll your own mechanism either. Web applications are trendy now, though, despite there being no objective advantage in most circumstances.

Refresh-less updating isn't new, either - I've been doing it for at least 3 years, without the XML stuff. Even with it there's only so much you can do on the client, by design. The web is a decent platform for reporting. It's a good place for universal access (see gmail, for example). It's a lousy place to put your data-entry heavy business applications.

Re:I have only one point to make.

[arkanes]

What's stopping it from happening is that the features that make a good browser for hypertext are not the same features that make a good client for, say, a business or data entry application. As a quick test, go hit the back button in any web application that uses this sort of technology. Does it do what you expect? Does the "back button" even make sense in the context of what you're doing?

Hypertext is a lousy way of writing applications - in fact, most "web apps" have roughly zero relationship with hypertext. Network-transparent thin clients are interesting, but HTML/DHTML/current browsers are the wrong way to implement these things. Part of the problem is the issue of control - client applications need to be able to control the user interface to a degree that a general purpose browser simply can't allow. Something as simple as "Save changes at exit" is impossible in a browser - and you wouldn't want it to be. Same thing with control of the back button, or spawning new windows (or even dialogs, which you can do with IE).

In short - the browser is a fundamentally poor platform for most applications. More to the point, we have and have had the technology for network-based application suites for years. ASP (application service providers, not the MS web platform) is gaining some mindshare, but it's not taking off like gangbusters.

S-expressions

[imbaczek]

It looks like the technology is finally converging towards Lisp. Maybe 40 years isn't THAT much, after all...

(If you think about it, it started quite a time ago, since xml is isomorphic to sexps.)