Is it safe to say that AJAX is a particular way of using HTTP?

Question

I really need someone to confirm the following, and if necessary help me filter what I have read so far.

• AJAX, which stands for Asynchronous JavaScript and XML, is used to exchange data and is a form of communication between client and server. Practically, it is used to retrieve data and update a page without having to refresh everything. However, on the inside, it is really using HTTP to send and retrieve data.

• HTTP, which stands for HyperText Transfer Protocol, is the core protocol used to communicate between client and server. Practically, it used to transfer resources (including files and other data) over the internet.

So it seems that AJAX is basically one way of using HTTP... and other ways of using HTTP include REST. Is that correct?

Answer 1

Ajax and rest are indeed two ways of using HTTP. But you can use both together.

HTTP (HyperText Transfer Protocol) is a protocol to send files (and data) from the server to the client. Originally it was intended to send static HTML files from the server to the client when the client's browser requested a (HTML) page. The HTML can contain hypertext links to other pages.
Later people started using HTTP to request the (HTML) results of programs that ran when client requested a file from the server (i.e. CGI, and later ASP and PHP). HTTP allows the client to post 'forms' to the server. The server CGI program could use the client's form to change the HTML page sent to the client.

AJAX is a way of using HTTP¹ where the never changing parts of a website (i.e. some html and the javascript files²) are separated from the changing data. After receiving the unchanging parts of the website the client (via the javascript it has received) makes more HTTP-requests to the server in the background: it sends data to the server and it receives data (not HTML pages) from the server. When the client has received the data, it uses it to update the page the user sees. Meanwhile the page remains responsive to the user.
Comparing this to the traditional CGI/ASP/PHP we see that instead of sending a web-form and waiting to receive a complete page in response, only the change parts of data are sent and they are sent in the background so that the page remains responsive to the user.

Rest is also a way of using HTTP. It's a reaction to some of the difficulties caused by the AJAX approach. In the AJAX approach all kinds of data is sent back and forth, all kinds of methods are called, the server expects the client to remember the data in both directions that was transmitted before, and the client expects the server to remember the same.
A difficulty is the the client and the server where heavily coupled to modify one, a programmer has to understand both. Finding which methods did what and which methods should be called when was quite a puzzle. A second difficulty was scalability. Operations could not just add an other server or a proxy when the load became to much, since client and server assumed that the other party knew the data transmitted before. Switching requests to an other server in the middle of a session between a client and a given server, would require careful planning and carefully sharing the client's state among the servers, which complicated the server code.

REST returns to some of the original principles of HTTP that AJAX has abandoned.

1. Don't use gazillions of different methods and ad-hoc error handling:
   • use the methods available in the HTTP protocol (mainly GET, POST, PUT, and DELETE); and,
   • use the HTTP status codes to signal various errors.
2. Assume the server and the client are unaware of each others state and of data transmitted previously.
   • Send all state required to handle a request with the request.
     Just as in ye olden days when the server sent a complete web page when a client requested it and the forgot about the client.
3. Structure the data as 'resources'³. With each being retrievable (and operable via POST and such) via an URL.
   • This combines the send pages approach of traditional static HTML and dynamic CGI/ASP/PHP HTTP and the separate data from page (static content) approach of AJAX.

Items 1. and 3. helps reducing the puzzle of which method does what, what data is transferred, when each method should be called: any client that 'speaks' HTTP can connect to the server program. The client still has to know what resources the server publishes, the URLs of these resources, and their meaning (semantics).
This allows for simpler clients.

Item 2 allows for operational scalability, since the client and the server are unaware of each other's state and the previously exchanged requests. Switching a client mid-session to a different server is easier. Clustered servers do not have to exchange their clients' state among themselves.
This allows easier scalability and simpler server programs.

AJAX and REST work well together; you don't have to choose either one or the other:

• Separate a dynamic page into static content (from the server's viewpoint) and dynamic content (an idea from AJAX).
• Retrieve changing data in the background (an idea from AJAX).
• Keep the page responsive to the user while retrieving data (an idea from AJAX).
• Update the page in place when the client has received the data (an idea from AJAX).
• Structure the data as well defined resources (an idea from REST).
• Publish these resources via a well defined schema of URLs (an idea from REST).
• Use standard HTTP methods to retrieve and modify the data (an idea from REST).
• Use standard HTTP status codes to signal errors (an idea from REST).
• Assume the client and the server know nothing about each others state and the requests sent before
  Transfer all state that is needed to handle the request in the request (and try to keep this to a minimum) (an idea from REST).

---

¹ _{AJAX choose to use HTTP as its communication protocol because most webpages where already already transmitted via HTTP and all web browsers could already communicate via HTTP.}

² _{The server considers javascript static content, its just a file, that never changes, that the server can send to the client. For the client the javascript is dynamic content since it contains instructions for dynamically updating the web page.}

³ _{A REST resource is a piece of data that is well defined in the application.}

Answer 2

So it seems that AJAX is basically one way of using HTTP... and other ways of using HTTP include REST. Is that correct?

REpresentational State Transfer (REST) is a way of designing communication protocols. It is a set of constraints placed upon communication protocols that by following these constraints allows these communication protocols to last a long time without needing to be changed.

HyperText Transfer Protocol (HTTP) is a communication protocol that by following the constraints of REST.

HTTP IS REST. REST is the big idea, and HTTP is a communication protocol that implements the big idea.

HTTP is a REST protocol. It is the original REST protocol, REST itself arose out of what was learned developing HTTP. HTTP (when used properly) constrains itself along the lines that REST requires, and as such can be considered a REST protocol. This is why HTTP hasn't need to be updated in over 10 years (the last version was HTTP 1.1)

Confusion arises because REST ended up being a catch all phrase for a lot of different things as people realised that they were using HTTP all wrong. Some developers went back to Roy Fielding's thesis on REST and realised that they were using HTTP not as intended. This lead to people trying to be more "RESTful" in how they used HTTP.

But like a lot of things in software development the meaning of that phrase got diluted as it was shared around and the original context was lost. You can now end up with people think RESTful just means using semantic URLs, or using PUT instead of POST. In fact RESTful just means using HTTP properly and focusing on Hypermedia as the engine of state change (hint is in the "H" in HTTP). Using HTTP properly though can involve quite a massive change depending on how badly HTTP was originally being used, switching to thinking of Hypertext as the agent of state change can be a huge mental shift for people. But it is what HTTP was originally designed for, so you can't really use HTTP properly if you aren't thinking in terms of HATEOS ("Hypertext As The Engine Of Application State")

So you don't really need to worry if you are doing REST properly, you need to worry if you are using HTTP properly. If you use HTTP properly you are, by definition, doing REST correctly.

AJAX is just a way of sending HTTP requests via Javascript rather than by manual intervention in the Browser. AJAX really doesn't have much to do with REST other than it uses HTTP, it is a feature of JavaScript.