Why JSON? I have done some tests today, and the request time for both JSON, or a normal AJAX request was the same. In the "normal request" I have returned the complete text+html tags, in the JSON request, logically I returned a "json return type" and I have created the HTML with client-side JavaScript.
I don't get it, why are the big sites (Google Reader etc), or even small sites using JSON? Or do I not understand when I should use JSON?
You are perhaps a little confused.
JSON and AJAX are not an either-or choice.
JSON and XML is a choice.
JSON and AJAX are distinct and largely unrelated, although AJAX often uses JSON, it can just easily use XML, HTML or plain text.
Or are you referring to the X in AJAX (XML)? If so, the arguments for JSON are basically:
JSON has a smaller payload than equivalent XML; and
JSON is easier to deal with in Javascript (compare eval'ing a JSON object to walking an XML fragment).
Other than that, it's largely personal preference.
JSON is just a data-interchange format. It describes in what way the data is represented during transmission. You can not replace Ajax with JSON.
Ajax stands for Asynchronous JavaScript and XML, but when using JSON you could say that you're using AJAJ (Asynchronous JavaScript and JSON).
Maybe you are thinking of the jQuery methods $.getJSON() and $.get()?
The difference is that $.getJSON() automatically assumes that it's JSON data, while $.get() will just fetch the data as plain text.
When using $.getJSON() you're also able to fetch data between domains.
Related
While writing node js APIs, we can send plain JSON objects as params (body params), I think there must be some additional overhead for the formatting instead what if I stringify the JSON while sending to API and will parse back to original JSON while processing it.
Can you guys please suggest if this approach gives any performance advantage?
JSON is "JavaScript Object Notation" — i.e. some string format to serialize Object, to save, transfer and restore Object to/via/from a string. JSON.stringify() does not mean you stringify JSON: JSON here is not an object of stringifying, but a namespace like in Math.sqrt(). You cannot transfer Object as is via HTTP or IPC: for this purpose, you have a text serialization format, i.e. JSON.
I've heard that JSON serializes all the data, which stops me having problems client side in terms of cross-browser support etc..
I've been using AJAX with jQuery and it seems easy, but I'm unsure of the differences,
I've read I can also use this to get the data:
$.ajax({
url: url,
dataType: 'json',
data: data,
success: callback
});
Can anyone explain the difference between making a jQuery AJAX request using JSON and making a jQuery AJAX request without the json type?
Will the answer be ok for all browsers?
I think you are confusing the terms.
AJAX stands for Asynchronous Javascript and XML, which is a mechanism used to launch asynchronous HTTP requests to a server using JavaScript. Don't let the name fool you; there's no restriction on you only retrieving JavaScript or XML from this technique. You can quite happily return other data formats as well (HTML, plain text and JSON, to list a few).
JSON is just one of these formats. It's a data interchange format, where-as AJAX is a technique to communicate with a server after the initate page load has completed.
To answer your question on whether you need to specify the dataType; jQuery will best guess the response format (be it HTML or JSON etc), so you're usually fine to omit it.
The dataType option simply changes what type of data jquery should expect from the server. It can be json, jsonp, html, text, xml, or any custom datatype that you define a converter for. They all work in all browsers.
By default jQuery will try to detect what type of data is being returned if you do not supply a dataType option, however I find that it doesn't automatically detect very well.
Edit:
but what if i need to return an object? is basically the answer of a database consult... is it better to use json or only jquery?
You can return an object in the form of html, xml, json, or jsonp. As long as it is in one of those formats, jQuery will be able to interpret it.
JQuery: It is a light weight Javascript Library.
JSON - Stands for JavaScript Object Notation.
Jquery:It is created using JavaScript and you will be using the inbuilt functionalities from the library.
Json: JSON is a text format that is completely language independent.
JQuery:It is a fast and minified JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.
Json: If you want assign data to Your grid then it is possible with Json.
From this site, I've learned that ASP.NET script services accepting JSON actually require them to be serialized JSON strings (see: "JSON, objects, and strings: oh my!" section of the link). Is there a quick and easy way to serialize them for ASP.NET AJAX consumption on the client side instead of trying to manually convert a bunch of existing objects to JSON-looking strings?
Thanks in advance!
You can use JSON.stringify() to serialize client-side objects for consumption in ASP.NET's Script Services.
Using that approach, you can map client-side objects to server-side objects very easily. ASP.NET will automatically handle converting the JSON to objects (or even collections of objects) for you.
The article writer is confusing Javascript objects with JSON strings. There is no such thing as a "JSON object".
Naturally if you try to send an object to a web service, it has to be serialised, as the request data can only contain text, not objects. The standard way of serialising data to be posted is URL encoding it, so that is what jQuery does.
There is no JSON serialisation built into Javascript or jQuery. You would have to do the serialising yourself or find a library that does it. Here are some options: Serializing to JSON in jQuery
Also, the data sent in the example is not valid JSON. It looks like this:
"{'fname':'dave', 'lname':'ward'}"
To be valid JSON it should look like this:
'{"fname":"dave", "lname":"ward"}'
I have an online service where users can create json-backed documents. These are then stored on a server and other users can load them. The json is then decoded exactly as it was submitted. Are there any security risks in the event that a user tampers with the json before they submit it and injects arbitrary javascript, which is then executed on the viewers' browser? Is this even possible? that's what I need to know, if this is possible, or arbitrary execution of javascript from a json string is possible.
This depends entirely on a) whether you're scrubbing the JSON on the server side, and (even more) on b) how you're decoding the JSON on the client side when you load it again.
Any code that uses eval() to deserialize the JSON into a Javascript object is open to exactly the attack you describe.
Any code that uses JSONP to load the JSON (i.e. passing the JSON as a Javascript literal to a named callback function) is open to the attack you describe (it's effectively the same as using eval()).
Most robust JSON-parsing mechanisms (e.g. json2.js, the jQuery $.parseJSON function, or native JSON.parse() functions in browsers that support it) will not accept JSON that doesn't follow the JSON specification. So if you're using a library to parse the JSON string, you may be safe.
No matter how you intend to load the JSON on the client side, it is good practice to scrub any user-submitted content on the server side. In this case, you might use server-side code to check that the JSON is valid (e.g. using json.loads(user_submitted_json) in Python, and catching errors).
So with some care on both the server side and the client side, you should be able to do this safely.
<plug shameless="true">
JSON sans eval is designed to avoid problems with malformed JSON while still being efficient at parsing.
This JSON parser does not attempt to validate the JSON, so may return a result given a syntactically invalid input, but does not use eval so is deterministic and is guaranteed not to modify any object other than its return value.
There are a number of JSON parsers in JavaScript at json.org. This implementation should be used whenever security is a concern (when JSON may come from an untrusted source), speed is a concern, and erroring on malformed JSON is not a concern.
</plug>
JSON has traditionally been parsed using an eval() statement, which is about as insecure as it is possible to get. If you allow this, your application will be insecure.
For a data send, where the return data contains potential updates for hundreds of elements on a page, is XML or JSON or another data format better, for usage with jQuery's various parsing formats (invoked via ajax() success)?
Check out this article, it outlines various pros/cons of XML, JSON and HTML when processing AJAX requests.
Personally I'd pick JSON as it uses less bandwidth & is easier to parse and use.
It sounds like a lot of data being returned so json. It's lighter and more compact. Plus it has native use instead of having to parse the xml and traverse it afterwards.
In javascript it is better to go with JSON because it is easier to code and less data to load from the server, unlike XML you have to write a code to parse the elements and fetch the values to your object and for every change in data tags or elements in XML you will need to modify your javascript code which means more coding and testing, unlike JSON all what you need is eval() and you are ready to go.