Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
My WebAPI was deployed in the Intranet environment. That means security was not my concern.
It seems that CORS is much more friendly to the client and easier to implement.
Any other concerns I might have missed?
This is a pretty broad question, and could warrant a wiki unto itself. There is also quite a bit on google regarding the two, but I think I can hit a few key points.
If you need a read-only ajax interface to your servers and you need to support IE<=9, Opera<12, or Firefox<3.5 or various other older or obscure browsers, CORS is out, use JSONP. IE8 and IE9 sorta support CORS but have problems, see the link in the first comment below.
On the other hand, if your web API is read/write (e.g. full REST or just POST/GET) instead of just read (i.e. GET), JSONP is out. Use CORS. JSONP is inherently read-only.
If neither of these are a concern, I would just go with whatever is easiest or most familiar to you. If its a tossup, try CORS, since it is the more "modern" solution and JSONP is more of a hack, turning data into scripts to bypass cross-domain restrictions. CORS does however, typically require more server-side configuration.
If you're using jQuery, I'm not sure where you're coming up with the idea that CORS is "much more friendly to the client and easier to implement." See https://gist.github.com/3131951 . jQuery abstracts the details of JsonP, and CORS can actually be somewhat tricky to implment on your server-side depending on what technology you're using.
I recently developed a web app, using jquery and backbone.js, which reads from various cross-domain web services that we control, and ended up using Json-P instead of CORS because we need to support IE7 and it was a bit simpler on the server side (we run Django w/ DjangoRestFramework), and virtually the same with jquery on the client side.
You are pretty spot on. If you don't have to support legacy browsers (ones released 6+ years ago) I would definitely go with CORS.
CORS is easier to implement, in that if your API doesn't already support JSONP or CORS it's easier to just add a few static headers than modifying the body of responses.
Also it's easier to cache requests using CORS. Each JSONP request needs to be dynamic even with memcached content.
JSONP is still a script tag, so no matter what it will cause some level of synchronous behavior. CORS will not.
JSONP can only be a GET. And as with CORS you can do use any method.
Last but not least, if you're using jQuery v1.x, consider that error and complete (or better fail and always) handlers are still not called for JSONP requests in some common situations (e.g. network errors). Sure there are workarounds (timeout setting, jQuery-JSONP plugin), but I find CORS less annoying, expecially when cross-domain requests are only coming from mobile devices (i.e. hybrid apps) so you don't need support for unlucky browsers.
According to Spring Documentation, JSONP is a hack and not a proper solution of Cross Origin Resource Sharing. So if security is not your concern then simply check your domain origin on your server and add Access-Control-Allow-Origin Response header.
Our Web API was not working on Safari (iOS 9.1) with Windows Authentication. It was working with Safari + iOS 8.4. When we changed to JSONP Safari started working again. Check this link for more information.
Related
I have a web app that will reside in a secure site (HTTPS) that needs to access other sites using http using javascript libraries.
Due to very valid security concerns this is not allowed in modern browsers but I can't control the other http sites that I need to access.
My question is: What are my best options for this (and only) particular case? I would like to be pointed in the direction of a minimal solution to the problem if possible.
Thanks!
Found the solution with Titanium Web Proxy.
Thanks
I'm designing a REST web API, but noticed something weird lately.
Apparently some proxy servers are blocking specific HTTP request methods. In my case the PUT and PATCH methods which are crucial to modify resources. This partially breaks the functionality of the API I'm designing...
Is there a good way to bypass this problem without breaking the RESTful architecture constraints? In my opinion there isn't, because fully using the HTTP verbs is advocated when designing a REST web API over HTTP...
You have a few options:
Ignore it. People who willingly break the(ir) web (experience) using a malconfigured proxy server will have to deal with the consequences themselves.
Ask the proxy administrators to whitelist your host or the methods it accepts.
Rewrite your API, "breaking" REST principles.
Use HTTPS, so the proxy will only see the connect method.
I am developing a application that is using backbone.js for most of the front end logic and was thinking of using sqlite for storage, but i have run into a few complications with it and need to switch to another NoSQL database.
I see on ravendb's site that it was created in C# and you need a .net compiler. Most of the docs are for ASP MVC type application. I can not go this root because we are developing this as a tablet application with no microsoft based technologies on the client side ( because we want it to work with android and apple )
The server however will be .NET and so i figured this might be do able. Just wondering if this is worth pursuing and if anyone has had any experience using ravendb? Or should i go for mongodb?
It is possible to expose RavenDB directly to a JavaScript application, sure. But it's usually not recommended. The main reason is security, but there are many other reasons to have a middle-layer.
For example, you often need a server-side location to perform application logic. Not everything can be done in the database itself, and if you do it all in the application then you will probably send a lot more data to the app than it really needs. Over the internet, that could mean a slow app.
The route many people take, is to use ASP.Net WebAPI, or ServiceStack, or another similar framework. This gives you a way to expose REST endpoints that your JavaScript app can call. You can connect to RavenDB from there.
Also, you seem to have the misconception that if you used ASP.Net MVC on the server that you couldn't target Apple or Android. That's just false. Whether you use a SPA approach or a traditional approach, you are delivering standards-based content, such as HTML, CSS, JSON and JavaScript.
Yes, You can use it. Actually RavenDB's server is a RESTful web service, which means you can work with it with any kinds of HTTP clients. These clients should be able to issue standard HTTP verbs like GET, PUT, DELETE etc.
ASP MVC is server side. I still at a loss as to why you would want to expose your db to a clientside piece. It is completely worth doing in a server side piece, but do not expose something like a db directly to your client.
I am trying to make a sencha touch 2 mobile app. I have a restful api in server and i want to consume that in my mobile app. Which sencha proxy should i use (rest, ajax, jsonp)? Rest and ajax has issue with cross-site domain issue, so jsonp can be the solution. But how can i send jsonp request to rest api if i have parameters?
You can use REST proxy if your services truly follows REST standards because that way proxy can provide you out-of-the-box functionality to operate on models.
Regarding cross-domain issues, please note that the way app behaves in desktop browser is different from its behaviour when it runs in phone so you are not forced to use JSONP if you don't want, AJAX can also work for you. Its good if you can use JSONP but please keep in mind its limitations of having no support for HTTP headers and other useful methods like POST, PUT & DELETE.
Please go through this for more information : How to use json proxy to access remote services during development
We wish to build a web app that will consume our REST API and looking for a way to circumvent the Same Origin Policy security feature.
We have a REST API which is served from api.ourdomain.com from SERVER_1.
We have a Web App which is server from dashboard.ourdomain.com from SERVER_2.
The Web App communicates with the REST API using ajax calls that include GET, POST, DELETE and PUT requests.
At some point in the future, we might consider allowing 3rd party sites to access the API from their own sites and domains.
Due to the Same Origin Policy security feature of the browsers, these requests are not allowed.
We are looking for ways to circumvent this.
Solutions we have encountered:
Tunneling the requests through our proxy. This will slow down the app and requires more resources.
JSONP - Will only work for GET requests. We do not wish to overload the GET requests with post/put/delete capabilities.
Using an iFrame with document.domain set to the same domain. Will only work for sites under ourdomain.com.
Frameworks such as EasyXDM. Seems like a good solution.
Thank you!
I don't know EasyXDM but I have the same architecture you are talking about in more than one application. We use your suggested solution (1). In my opinion proxying the requests through a common subdomain is the cleanest solution. I don't think that this is a performance problem. Many sites use something like nginx anyway to do some sort of reverse proxy (as cache). You could easily tunneling your API through http://[yourhost]/api and the rest of the HTML, CSS and image resources through other paths.