Slashdot Log In
What is JSON, JSON-RPC and JSON-RPC-Java?
Posted by
Hemos
on Mon Jan 24, 2005 08:32 AM
from the pushing-the-development-forward dept.
from the pushing-the-development-forward dept.
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/ "
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
O...k..... (Score:3, Funny)
*finishes reading summary*
ok... so... huh?
Re:O...k..... (Score:4, Informative)
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)
Parent
Re:O...k..... (Score:4, Insightful)
So now people can't bookmark specific products
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.
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.
Ummm... why would you want an RSS new ticker on a webpage in the first place?
Yes, lets just create something with no practical advantages over Flash/Iframe, but which requires a more recent browser to access.
Parent
Re:O...k..... (Score:5, Interesting)
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;
Parent
Re:O...k..... (Score:3, Interesting)
So (some) Vendors want it, and (some) Web Developers want it becuase the Vendors (their clients) want it - but does it bring any serious benefit to the end user?
Changing product images is a reasonable thing to do - but all that needs is a change in the src of the <img> (Or you can take the thinkgeek approach and have nice, large images that show lots of details and that a full page reload doesn't add any significant bandwidth needs to)
1-minute rotation? How long to people spend on a single page t
Re:O...k..... (Score:4, Insightful)
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.
Parent
Re:O...k..... (Score:3, Insightful)
Re:O...k..... (Score:4, Insightful)
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.
Parent
Pros and cons? (Score:5, Interesting)
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? (Score:4, Informative)
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.
Parent
Re:Pros and cons? (Score:2)
Re:Pros and cons? (Score:5, Informative)
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...
Parent
Re:Pros and cons? (Score:3, Informative)
You're right, the expected client is JavaScript, inside a browser. The frontend UI is typically in HTML (or SVG), but the client-side logic is written in JavaScript. In this case, the request/response happens within a web-page, between the browser and the web server.
HTML forms are one mechanism for client-server data transfer in a browser, but posting them necessitates reloading the entire web-page, or an iframe, which is not seamless for interfaces like Google Suggest, and may be overkill if you're only
I have only one point to make. (Score:2, Insightful)
Re:I have only one point to make. (Score:2, Interesting)
Only computationally expensive programs will be relegated to the desktop, everything data orientated will live on the web
Re:I have only one point to make. (Score:2)
I dare to disagree. (Score:2, Insightful)
Re:I dare to disagree. (Score:4, Insightful)
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.
Parent
Re:I have only one point to make. (Score:2)
Yes, but how many applications make is so easy to give you access to such a wide variety of viruses? I kid, I kid.
Actually, I agree with the parrent on this one. I prefer applications to have their own gui. This can help where speed of use is an issue. Also, if you buy software, throw the cd in, and all that is on the cd are a bunch of
Re:I have only one point to make. (Score:5, Insightful)
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.
Parent
Re:I have only one point to make. (Score:4, Insightful)
> 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.
Parent
Re:I have only one point to make. (Score:3, Interesting)
*use xhtml only
*use extremely light html (under 10k if I can help it)
*no graphics
*no fancy nothing
*javascript sparingly (and yes I use xml-rpc to do no-refresh data submits) (Apple, fix Safari's DomParser stuff. See http://developer.apple.com/internet/safari/safari _ faq.html#anchor19 [apple.com].)
As far as server technology, remember to load the minimum (files, class libs, etc), optimize db queries, split pages logically for the USER, pool db connections, and re
Re:I have only one point to make. (Score:3, Insightful)
Exactly that is something to worry about! Imagine you are writing something important with a web-based word processor. You are close to deadline, and all you have to do now is to print out that stuff (or to convert it to PDF and mail it). Nobody would be so insane to update his word processor at exactly this point. But with web
Re:I have only one point to make. (Score:4, Insightful)
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.
Parent
Look to Google for the future (Score:3, Insightful)
Look at what they have done, and what they have not done - GMail has a very good interface. But even Google has released some real applications, like desktop search and Picassa.
I really believe the browser model can only be taken so far. As someone else noted, your browser becomes your window manager and pretty soon you develop a little cosmos in there. But that cosmos will always be a subset of the richer cosmos the OS itself offers, and so web apps
Re:I have only one point to make. (Score:5, Insightful)
Parent
Re:I have only one point to make. (Score:5, Interesting)
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.
Parent
Re:I have only one point to make. (Score:4, Insightful)
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.
Parent
Click below to read more about it. (Score:5, Funny)
Let me guess... (Score:2)
Fix HTML instead? (Score:3, Insightful)
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? (Score:3, Insightful)
Re:Fix HTML instead? (Score:4, Interesting)
Parent
And what about php? (Score:2, Interesting)
If you want to interoperate with PHP, I'd suggest Harry Fuecks JPSPAN [sourceforge.net] as it is quite nice at hooking javascript up with serverside php
As for xmlhttprequest, it's rather easy to make neato web applications with it. Here's something I coded up the other night (only seems to work in firefox at the moment though): http://www.james-carr.org/index.php?p=8
Cheers,
James Carr [james-carr.org]
Perfect for the web? I don't think so (Score:5, Interesting)
Example in JSON:
The same thing in XML:
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 (Score:5, Informative)
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).
Parent
Re:Perfect for the web? I don't think so (Score:3, Insightful)
JSON-RPC doesn't seem to be intended for use in interchange, but for websites, since it relies on browser security for the 'efficiency' of being able to use eval() in its
ICBW but: Re:Perfect for the web? I don't think so (Score:3, Informative)
Re:Perfect for the web? I don't think so (Score:3, Informative)
double edged boon to users (Score:2, Insightful)
The user benefit will come from more usable dynamic web applications when this is applied well. The users will suffer when everbody decides their pages need this even when they don't. Kiss that CPU goodbye. The users will get to suffer when they decide to use a platform that didn't rank high enough for the sites QA team to bother checking.
When used and tested well, this can provide some awesome benefits. Hopefully, we'll see more than simple ad/news/stock tickers. Im
AAARRGH! (Score:2)
Another language, another standard (Score:2, Funny)
New exploit techniques ? (Score:3)
I hope I wasn't the only one that shuddered when I read "remote scripting techniques".
Pushlets (Score:4, Informative)
This is a server side push framework based on the same idea. It preceded GMail et alia.
Or instead... (Score:3, Informative)
All JSON does is make it easier to have your JavaScript call in to your application and parse the results. If you're just interested in presentation, just have your JS call up, get some HTML, and replace the affected HTML. This decreases the amount of JS and increases your re-use (since you don't need to build your UI twice: once is (PHP|Java|.Net|Ruby|.*), and once in JS). You just call your (\1) code on the server from the JS and have it generate the HTML.
I understand that sometimes there are advantages to the programmatic approach that JSON (and XML-RPC, which the browsers support) extoll, but I don't think many developers even realize the UI-based alternative.
3270s (Score:3, Informative)
Hey, 3270s were coax-connected to a channel-attached controller with a 4.5MB/sec path to the CPU. You could do video on them (if you didn't mind the fact that your pixels were the size of a tic-tac.
A.
(who lusts for the feel of a 3270 keyboard under his fingers)
Back to the future: Web = CICS? (Score:3, Informative)
However, your memory of 3270's is a lot different than mine. How about when that nifty wifty 3270 cluster controller went south, as
S-expressions (Score:3, Funny)
(If you think about it, it started quite a time ago, since xml is isomorphic to sexps.)
Different than ASP.NET script callbacks? (Score:3, Interesting)
http://msdn.microsoft.com/msdnmag/issues/04/08/Cu
Advantages to hidden iframe (Score:3, Informative)
You could use the JSON as message format with hidden iframes, too.