Can anyone help me in understanding the differences between JSON, JSONP & CORS, from an asp.net MVC perspective?
JSON is a data format, while JSON-P and CORS are mechanisms/protocols for making cross-domain requests for data.
JSON is a format for representing data. It was first defined in JavaScript, but has grown to become a de facto way for APIs to represent data. Most languages have libraries for parsing JSON. You can learn more about this format here: http://json.org/. Here's an example JSON object:
{
"key": "value"
}
JSON-P is a mechanism for loading data in JavaScript. It bypasses the browser's same-origin policy in order to load data from another domain. It does this by embedding a JavaScript script on the page. This script calls out to the remote domain, which returns data wrapped in a JavaScript function. When this function returns to the browser, it is executed, which allows the calling code to access the data.
Note that while the name has the word "JSON", JSON-P doesn't necessarily have to work with JSON. For example, it could return a string or any other valid JavaScript data type back to the user.
Note that while JSON-P works in every browser, it is a hack to get around the browser's same-origin policy, and it has some limitations. For example, it can only issue a GET request, and the caller doesn't have access to the response headers. Since it is custom to browsers and JavaScript, JSON-P is not really appropriate for accessing data from other languages, like server-side Python.
You can learn more about JSON-P here: http://en.wikipedia.org/wiki/JSONP
CORS is a standardized mechanism for making cross-domain requests. It is supported in most modern browsers. The client uses the standard XmlHttpRequest object to make a CORS request. Upon receiving the request, the server decides whether the cross-domain request is allowed. If it is allowed, the server issues special headers that allows the response to be passed on to the client.
You can find the CORS spec here: http://www.w3.org/TR/cors/
You can learn more about how to use CORS here: http://www.html5rocks.com/en/tutorials/cors/
All these technologies are independent of ASP.NET MVC. If you'd like to use these technologies, you should first ask yourself "Do I need to access data across domains?" If the answer is "yes", you should then ask "What browsers/platforms do I need to support?" If your answer is "most modern browsers", then you should consider implementing CORS. Otherwise you should use JSON-P
CORS is a specification which has nothing to do with JSONP beyond making it obsolete in newer browsers. It enables cross-domain requests using ordinary XMLHttpRequest calls.
Here's an overview of how it works and how to use it. It can be used in Firefox 3.5+, Safari 4+, Chrome 3+, Internet Explorer 8+, and anything else using one of the same engines.
for details go on reading
http://json-p.org/
Related
I was playing around with GZIP compression recently and the way I understand the following:
Client requests some files or data from a Web Server. Client also sends a header that says "Accept-Encoding,gzip"
Web Server retrieves the files or data, compresses them, and sends them back GZIP compressed to the client. The Web Server also sends a header saying "Content-Encoded,gzip" to note to the Client that the data is compressed.
The Client then de-compresses the data/files and loads them for the user.
I understand that this is common practice, and it makes a ton of sense when you need to load a page that requires a ton of HTML, CSS, and JavaScript, which can be relatively large, and add to your browser's loading time.
However, I was trying to look further into this and why is it not common to GZIP compress a request body when doing a POST call? Is it because usually request bodies are small so the time it takes to decompress the file on the web server is longer than it takes to simply send the request? Is there some sort of document or reference I can have about this?
Thanks!
It's uncommon because in a client - server relationship, the server sends all the data to the client, and as you mentioned, the data coming from the client tends to be small and so compression rarely brings any performance gains.
In a REST API, I would say that big request payloads were common, but apparently Spring Framework, known for their REST tools, disagree - they explicitly say in their docs here that you can set the servlet container to do response compression, with no mention of request compression. As Spring Framework's mode of operation is to provide functionality that they think lots of people will use, they obviously didn't feel it worthwhile to provide a ServletFilter implementation that we users could employ to read compressed request bodies.
It would be interesting to trawl the user mailing lists of tomcat, struts, jackson, gson etc for similar discussions.
If you want to write your own decompression filter, try reading this: How to decode Gzip compressed request body in Spring MVC
Alternatively, put your servlet container behind a web server that offers more functionality. People obviously do need request compression enough that web servers such as Apache offer it - this SO answer summarises it well already: HTTP request compression - you'll find the reference to the HTTP spec there too.
Very old question but I decided to resurrect it because it was my first google result and I feel the currently only answer is incomplete.
HTTP request compression is uncommon because the client can't be sure the server supports it.
When the server sends a response, it can use the Accept-Encoding header from the client's request to see if the client would understand a gzipped response.
When the client sends a request, it can be the first HTTP communication so there is nothing to tell the client that the server would understand a gzipped request. The client can still do so, but it's a gamble.
Although very few modern http servers would not know gzip, the configuration to apply it to request bodies is still very uncommon. At least on nginx, it looks like custom Lua scripting is required to get it working.
Don't do it, for no other reason than security. Firewalls have a hard or impossible time dealing with compressed input data.
I just got to know about the same origin policy in WebAPI. Enabling CORS helps to call a web service which is present in different domain.
My understanding is NOT enabling CORS will only ensure that the webservice cannot be called from browser. But if I cannot call it from browser I still can call it using different ways e.g. fiddler.
So I was wondering what's the use of this functionality. Can you please throw some light? Apologies if its a trivial or a stupid question.
Thanks and Regards,
Abhijit
It's not at all a stupid question, it's a very important aspect when you're dealing with web services with different origin.
To get an idea of what CORS (Cross-Origin Resource Sharing) is, we have to start with the so called Same-Origin Policy which is a security concept for the web. Sounds sophisticated, but only makes sure a web browser permits scripts, contained in a web page to access data on another web page, but only if both web pages have the same origin. In other words, requests for data must come from the same scheme, hostname, and port. If http://player.example tries to request data from http://content.example, the request will usually fail.
After taking a second look it becomes clear that this prevents the unauthorized leakage of data to a third-party server. Without this policy, a script could read, use and forward data hosted on any web page. Such cross-domain activity might be used to exploit cookies and authentication data. Therefore, this security mechanism is definitely needed.
If you want to store content on a different origin than the one the player requests, there is a solution – CORS. In the context of XMLHttpRequests, it defines a set of headers that allow the browser and server to communicate which requests are permitted/prohibited. It is a recommended standard of the W3C. In practice, for a CORS request, the server only needs to add the following header to its response:
Access-Control-Allow-Origin: *
For more information on settings (e.g. GET/POST, custom headers, authentication, etc.) and examples, refer to http://enable-cors.org.
For a detail read, use this https://developer.mozilla.org/en/docs/Web/HTTP/Access_control_CORS
Does the YouTube Data API Client Library for Java use Etags and/or gzip, as described at Getting started page?
Documentation is short (only find java docs) and don't say anything about it, so i guess is just a wrapper.
Based from this link, Etags are supported by youtube but it depends on what kind of data you are asking.
To use the etag, create a header request and put "If-None-Match" equal to your etag value. Note this should be a request header and not appended to the endpoint call. You can also use "If-Match".
Depending on what kind of API you are using, the way of inserting a new value to the request header may differ slightly. The ETag response-header field provides the current value of the entity tag for the requested variant.
You may also check on this related thread.
I am developing a web application with Dart using redstone and polymer
Because Dart allows for server and client side development, I wonder what a good pattern for a web application is (specifically to Dart)
Option 1:
Have a server, say, /bin/server.dart
1.1. get a request there and respond with json
#app.Route("/user/:id", methods: const [app.GET])
getUser(int id) { ... }
have a client, i.e. web/user.html and web/user.dart
2.1 in user.dart make a request to server
2.2 receive json and form a proper user.html
Option 2:
Have a server /bin/server
1.1 get a request there and respond with an html page, similar to
#app.Route("/")
helloWorld() => "Hello, World!";
If in the first case I more or less know (and understand) how to make things work, while i find it really frustrating that I do not take advantage of Dart's server-client code-sharing: I need to encode to and decode back json to get the same data. Is there a way to avoid it?
The second option is much less clear for me: how would I serve a web page in this way? How would I make Polymer do its work?
Answers on the questions in the text and a general explanation of a darty way to develop web apps are very much appreciated.
You can see a Redstone + Polymer application example here: https://github.com/luizmineo/io_2014_contacts_demo
Basically, it works as Option 1: The client and server communicates through a service API, and the data is encoded as JSON. Although, Redstone uses the shelf_static package to serve the client code to the browser as well.
If you prefer, it's also possible to use a server side template engine, such as mustache, to build html pages in the server, although, I think it would be really difficult to integrate that with Polymer.
And finally, you always have to encode the data someway when transferring data between client and server, but this doesn't means they can't share code. They can use the same domain classes, for example. Check out the sample application linked above for more details.
I don't think the option 2 is possible. Polymer depends on dart:html which is not allowed on server side.
I found the MVC API Action filter which should automatically check if the request demands a json response and if so automatically serialize in json the model i was sending to the view, right ?!
http://mvcapi.codeplex.com/
I found many examples but the thing is they all assume that the request will be sent by an Ajax call in which i can clearly specify it's a json request.
I want to call the action directly from my browser but i'm not without any specification it simply returns the view
How do i specify in the url that i'm requesting a json response?
I know of the library that you write of, but haven't used it. I shied away from using it when I saw that it never seems to have made it out of Beta on Codeplex and hasn't been updated in over a year.
That aside, in the methodology being used, the URL doesn't determine the data type coming back, the Http Accept Headers are what does it. This is a more RESTful approach to returning data.
You'll note on the link that you provided in the Request section that
Accept: application/json, text/javascript, */*
application/json is what tells the service to return json. You may find other examples on the web that say text/json instead, and they should work also, but application/json is the correct standard.
If you're using jQuery, you can use $.ajax and specify dataType: 'json' or just use the $.getJson method directly.