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.
Related
As I found, it is possible to manipulate and change Ajax code in browser console by client. For example, Ajax wants to call a method and pass id to controller. As I mentioned above, how we can secure our code from interference by client?
Thank you all
Security must always be implemented on the server side, because anything you do on the client side can be ignored, overstep, modified, etc very easily. In fact, anyone can use software like Postman to make a completely custom HTML request to any server.
Don't ever rely on any client-side software in terms of security for your server. If you want keep your server safe, then make a safe server.
I know all about SQL injections, and peeking into javascript files that a website uses, and also that GET requests contain all of the information in a URL.
Is there any security concern that is special to AJAX and only pertains to using AJAX?
For example, sending post requests via AJAX seems completely safe to me. Barring SQL injections, I can't think of one thing that could go wrong... is this the correct case?
Also, are "requests" of any kind that a user's browser sends or any information it receives available to be viewed by a third party who should not be viewing? And can that happen to AJAX post requests ('post' requests specifically; not 'get')?
It's like any other form of data input: validate your values, check the referrer, authenticate the session, use SSL.
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.
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.
I'm been reading up on Ajax and would like to see from the stackoverflow community if I'm understanding everything correctly.
So the normal client server interaction is a user pulls up a web browser types in a url and a HTTP request is sent to the server requesting the page and resources( css, pics ) from the web server. The web server responds to the client via HTTP the page/resources requested and the browser renders the html/JavaScript for the user to view the page.
1) So would it be safe to say that XMLHttpRequest( XHR ) object is doing the same process as the browser except your not requesting html from the server, your requesting text in some type of format?
2) Is it true that a XHR object is much like a regular object that can be manipulated by the program creating the object( like a normal object ), but also sends and receives data with another program( web server ) via HTTP?
3) So in my mind when a XHR is created it is loaded into memory and we setup some of the objects arguments when we do the request.open(“GET”, url, true). Once we do a request.send(null) the object basically attempts to “GET” the url via HTTP and once we get the data back from the server it is put in the responseText argument. Am I understanding this correctly?
4) Also synchronous vs asynchronous. When I think of synchronous I think of steps having to be followed in order. For example, I push a button, data gets sent to server, and I have to wait for data to come back before I can do anything else. With asynchronous connections I would push button, data gets sent to server, I do what ever I want while data gets sent back. Is this a good analogy?
1) Nope. The XMLHttpRequest object does exactly what its name implies -- it initiates an HTTP request. This request can be in XML, or HTML, or PHP. At the end of the day, the browser doesn't care, because in an AJAX request, it doesn't parse the request -- you have to do it yourself. So it doesn't automatically render the HTML from an AJAX request.
2) I'm not sure about manipulation (the XHR object may be immutable) but possibly. Would you ever need to extend it or manipulate it?
Yes, you can change properties of the object and so on. I apologize. I didn't understand you at first :)
3) Yep.
4) That's a great analogy. It's exactly what happens. Another analogy is a 4 lane highway is to asynchronous as a one-way street is to synchronous. If one car breaks down on the 4 lane highway, the rest can keep moving at their normal speed -- but if one breaks down on the one-way road, everything freezes. :)
Here I leave you a good graphic to see clearly the behavior differences between the synchronous and asynchronous application models:
(source: adaptivepath.com)
It would appear that you have a job grasp of how AJAX works. I can't see much to disagree with in your summary of the plumbing of an AJAX application.
I would say however that with the XMLHttpRequest object you aren't restricted to GET. You can also use POST and other HTTP verbs.
With async calls you register a callback function, the XMLHttpRequest object calls your method when the async request completes.
Seems ok to me.
Your first point though is not entirely correct, you can request html from the server using ajax is doesn't have to text, json or xml like most examples show.