So, I implemented an API provider to be accessed by both web application and mobile applications.
Most likely this will not be a large scale project, but I want to maximize my learning experience and geek out where I can.
Anyway, from what I understand, it seems like it's better to put the API provider service and the actual website on separate domains to make scaling easier.
For example, twitter has the website twitter.com and api.twitter.com.
One immediate issue would be dealing with the cross-domain issue with AJAX.
From what I gather, there are 2 ways to implement cross-domain AJAX
JSONP: I heard about it, but don't know much beyond the name
Proxy Server: so, my website is build on top of ASP.NET MVC and I was thinking about creating a APIProxy controller to handle all cross-domain API requests.
That way, I would make an AJAX call via $.ajax(settings) and then pass in the website URL that corresponds to the APIProxy controller. The APIProxy controller would then make the appropriate POST server calls and process the JSON responses and return the response back to AJAX callback functions.
I heard about flXHR about I don't want to use Flash because devices like the iPad or any a lot of mobile browsers don't support Flash.
Anyway, I just wanted to ask what are some of the best practices in managing a website with the API provider on a separate domain or subdomain.
When you request some JSON, it returns an object or array. Script tags are not subject to the same-domain rule. So instead making an AJAX call, you would essentially do this:
<script src="Http://api.example.com?param1=something&etc"></script>
That would load the JSON, and it would execute as JavaScript.
...But a simple object or array "executing" by itself isn't very useful. So when you request the JSON, you also include the name of a callback function. If the provider sees that a callback was provided, instead of just returning JSON, it actually returns JavaScript: the JSON is passed to your function as an argument.
Then, when the script loads, your function (which you already defined) is called, and given the JSON to work with.
That's JSONP.
Bibliography
Newton, Aaron. "Request.JSONP." Clientcide. 7 Dec. 2009. Web. 28 Jan. 2011.
Related
So I'm looking for a way to keep making GET/AJAX calls on user input from somewhere in my client side code to an external address, for eg: http://www.busbud.com/en/complete/locations/Ca?callback={fn} and to return the body from that page.
What's the best way to do this?
you can use jQuery ajax method with JSONP as data type to make cross-domain calls.
I have tried it successfully for a facebook app on express.
http://codeforbrowser.com/blog/cross-domain-request-with-jquery-and-jsonp/
I have recently been experimenting with building a cross domain web api, and wow has it been a bumpy journey. I have not had any problems with modern browsers such as Chrome, FF and Safari. The problem is with IE, which requires you to use XDR as opposed $.ajax when making cross domain calls. First Question: If I was using Backbone.js, what is the recommended way of making cross browser and cross domain ajax calls?
Another problem I had with IE was that when you make cross domain ajax requests, IE has a bunch of restrictions and limitations such as "Only text/plain is supported for the request's Content-Type header" - a link. Therefore in my case, I was unable to bind to my model using the MVC C# framework, unless I bind it manually.
Anyway my second and last question is: How do companies like Instagram, Facebook, and Twitter go about building their API's? I am not looking for a complete guide, but just want to know how difficult it is.
JSONP
The current standard is using JSONP. It is basically a trick to send a JSON payload wrapped in a single JavaScript function, the browser treats it like a script file and executes it.
CORS
Moving forward the way to go is CORS. Sadly browser support (IE) isn't there yet and there are still some implementation differences between the modern browsers that do implement it.
HTTP Method Overloading
Some APIs overload GET and POST request using X-HTTP-Method-Override: PUT or ?_method=PUT.
easyXDM
A number of API providers implement easyXDM. This tends to be used more when they provide a JavaScript API or widget API where developers load their JS and integrate it directly in to the frontend code.
I've created a RESTful API that supports GET/POST/PUT/DELETE requests. Now I want my API to have a Javascript client library, and I thought to use JSONP to bypass the cross-domain policy. That works, but of course only for GET requests.
So I started thinking how to implement such a thing and at the same time trying to make it painless to use.
I thought to edit my API implementation and check every HTTP request. If it's a JSONP requests (it has a "callback" parameter in the querystring) I force every API method to be executed by a GET request, even if it should be called by other methods like POST or DELETE.
This is not a RESTful approach to the problem, but it works. What do you think?
Maybe another solution could be to dynamically generate an IFrame to send non-GET requests. Any tips?
There's some relevant points on a pretty similar question here...
JSONP Implications with true REST
The cross-domain restrictions are there for a reason ;-)
Jsonp allows you to expose a limited, safe, read-only view of the API to cross domain access - if you subvert that then you're potentially opening up a huge security hole - malicious websites can make destructive calls to your API simply by including an image with an href pointing to the right part of the API
Having your webapp expose certain functionality accessed through iframes, where all the ajax occurs within the context of your webapp's domain is definitely the safer choice. Even then you still need to take CSRF into consideration. (Take a look at Django's latest security announcement on the Django blog for a prime example - as of a release this week all javascript calls to a Django webapp must be CSRF validated by default)
The Iframe hack is not working anymore on recent browsers, do not use it anymore (source : http://jquery-howto.blogspot.de/2013/09/jquery-cross-domain-ajax-request.html)
What are the benefits of a XML HTTP request? A given server could send data (e.g. some JSON serialization) for a normal request (non-XHR) as it would send data for a XHR request. And that data could be processed asynchronously (by a browser for example) as well. So why was the XMLHttpRequest invented?
Some things I can think of:
To use the same URL for HTML and a web service
To let the server know that this must be processed fast.
As far as I recall, one of the first uses of XmlHttpRequest was for OWA, which used WebDAV on the wire. So show me how to do methods other than GET/POST without it.
One important thing about XHR is that it's asynchronous and you can have several concurrently running XHR requests. For example you can have several informers on your web page, all updating independently and concurrently.
XMLHttpRequest (or ActiveXObject in IE) is what allows Javascript to make HTTP requests. It was created to be able to retrieve data in Javascript without having to change the page/refresh the browser.
There are non-javascript ways of retrieving data without refreshing the page, but if you are using Javascript XMLHttpRequest is the way to go. Many libraries have simplified the use of this call by implementing ajax functions in their libraries (jQuery.ajax() for example) which causes most people to not even realize that XMLHttpRequest is the underlying call behind it.
I think the biggest reason it exists is that it predates an Ajax JSON request. It was originally the only way to do AJAX based things. It's still useful when requesting an HTML page and populating an HTML element with the information requested. It's much simpler to use XHR in that instance instead of parsing the JSON and reading out a variable.
I guess the simple answer is that if you're looking for a single piece of data it would be a simpler request to process.
what is different between ajax and webservices. Anybody provide with some examples?
It's nonsensical to compare these things.
"Ajax" is a process that occurs in the browser. It is the act of calling some local server-side page, without refreshing the "main" viewing area, and then doing various things with that result (grabbing the data, making changes, changing the existing DOM (adding elements), whatever).
Webservices are a Serverside-thing that allows you to call methods, in your code, but have that call actually go to a remote machine. The call to the Webservice is generally also made server-side.
The term "Ajax" is generally used :
When the request is sent by a browser (client-side) to a server
When the transfered data is XML or JSON or HTML.
The word "webservice" is generally used :
When the request is sent by a server to another server, without a browser being involved
When the transfered data is SOAP -- at least when it's a SOAP webservice ^^ (Opposed to REST, for instance, which generally doesn't imply SOAP)
But I'd say that Ajax is basically some specific kind of webservice.
i think ajax and web services are kind of similar, here is why i think so.
as i understood it, in your app sometimes you will have to implement an "API" which has several useful functions. and it is those functions which are called "web services". these 'functions' acts in response to the http requests and "does" something with the data provided.
in ajax siimilar kind of work happens as well,just through javascript thats it.
so, to sum it all up, an API has 'web services' within it, and ajax behaves like 'web services'. in this manner, yes i think it is correct to call ajax and web services similar.