Network Requests

Mary Prtavyan
 Table of Contents

● Synchronous Web Communication

● AJAX and Asynchronous Web Communication
● Ajax Battle: XMLHttpRequest vs the Fetch API
● Websocket vs HTTP
● RESTful APIs
 Synchronous Web
Communication

synchronous: user must wait while new pages load

the typical communication pattern used in web pages (click, wait, refresh)
 Asynchronous Web
Communication

asynchronous: user can keep interacting with page while data loads
communication pattern made possible by Ajax XMLHttpRequest
 Fetch

Stages of getting a response

1. the promise, returned by fetch, resolves with an object of

the built-in Response class as soon as the server responds
with headers.

2. get the response body, we need to use an additional

method call.
Promise-based methods provided by
Response

● response.text() – read the response and return as text,

● response.json() – parse the response as JSON,
● response.formData() – return the response as FormData object (explained in the next
chapter),
● response.blob() – return the response as Blob (binary data with type),
● response.arrayBuffer() – return the response as ArrayBuffer (low-level representation of
binary data),
● additionally, response.body is a ReadableStream object, it allows you to read the body
chunk-by-chunk
 FormData

FormData Methods

● formData.append(name, value)
● formData.append(name, blob, fileName)
● formData.delete(name)
● formData.get(name)
● formData.has(name)
‘Ancient’ ways of communicating with
another server

Using forms
One way to communicate with another server was to submit a <form> there. People
submitted it into <iframe>, just to stay on the current page

Using scripts
Another trick was to use a script tag. A script could have any src, with any domain, like
<script src="http://another.com/…">. It’s possible to execute a script from any website.
 Cross-Origin Requests

1. Safe requests. 2. All other requests.

Safe method: GET, POST or HEAD Any other request is considered “unsafe”
Safe headers – the only allowed custom headers are:

● Accept,
● Accept-Language,
● Content-Language,
● Content-Type with the value
application/x-www-form-urlencoded,
multipart/form-data or text/plain.
CORS for safe requests

The browser plays the role of a

trusted mediator here:

1. It ensures that the correct

Origin is sent with a
cross-origin request.
2. It checks for permitting
Access-Control-Allow-Origin in
the response, if it exists, then
JavaScript is allowed to access
the response, otherwise it fails
with an error.
“Unsafe” requests
 XMLHttpRequest

method – HTTP-method. Usually "GET" or "POST".

URL – the URL to request, a string, can be URL object.
async – if explicitly set to false, then the request is synchronous
user, password – login and password for basic HTTP auth (if required).
 Ajax Battle:
XMLHttpRequest vs the Fetch API
Fetch

Advantages Disadvantages

● You can use the Cache API with the ● missing a built-in method to consume
request and response objects; documents
● You can perform no-cors requests, ● no way to set a timeout yet
getting a response from a server ● can't override the content-type response
that doesn't implement CORS. You header
can't access the response body ● if the content-length response header is
directly from JavaScript, but you present but not exposed, the body's total
can use it with other APIs (e.g. the length is unknown during the streaming
Cache API); ● will call the signal's abort handler even if
● Streaming responses (with XHR the the request has been completed
entire response is buffered in ● no upload progress (support for
memory, with fetch you will be able ReadableStream instances as request
to access the low-level stream). This bodies is yet to come)
isn't available yet in all browsers, ● doesn't support
but will be soon. --allow-file-access-from-files (chromium)
XMLHttpRequest

Advantages Disadvantages

● Abort a request (this now works in ● there's no way to not send cookies (apart
Firefox and Edge, as from using the non-standard mozAnon
@sideshowbarker explains in his flag or the AnonXMLHttpRequest
comment); constructor)
● Report progress. ● can't return FormData instances
● doesn't have an equivalent to fetch's
no-cors mode
● always follow redirects
Convenience measure
Regular Polling vs Long Polling
Regular Polling
Downsides
1. Messages are passed with a delay up to
10 seconds (between requests).
2. Even if there are no messages, the
server is bombed with requests every 10
seconds, even if the user switched
somewhere else or is asleep. That’s quite
a load to handle, speaking
performance-wise.
Long Polling
 Long Polling: The Flow
1. A request is sent to the server.
2. The server doesn’t close the connection until it has a message to send.
3. When a message appears – the server responds to the request with it.
4. The browser makes a new request immediately.

If the connection is lost, because of, say, a network error, the browser immediately sends a new request.
WebSocket
The Connection
Websocket vs HTTP
When can a web When not to use
socket be used: it?

● Real-time web application ● if we want to fetch old

● Gaming application data, or want to get the
● Chat application data only once to process
it with an application we
● if we want any real-time
should go with HTTP
updated or continuous
protocol
streams of data that are
being transmitted over the
network.
WebSocket vs HTTP
Websocket connection HTTP connection
● bidirectional ● unidirectional
● reuses the established ● works on top of TCP protocol
connection channel ● we can create the connection
● the connection is kept alive by using HTTP request
until terminated by either the methods
client or the server. ● after getting the response
● most real-time applications HTTP connection get closed.
use WebSocket to receive the ● Simple RESTful application
data on a single uses HTTP protocol which is
communication channel. stateless.
● all the frequently updated ● When we do not want to
applications used WebSocket retain a connection for a
because it is faster than HTTP particular amount of time or
Connection. reuse the connection for
transmitting data;
● an HTTP connection is slower
than WebSockets.
RESTful APIs
Advantages of REST
● REST API is easy to understand and learn, due to its simplicity.
● With REST API, being able to organize complicated applications & makes it easy to use
resources.
● The high load can be managed with help out of HTTP proxy server & cache.
● REST API is easy to explore and discover.
● It makes it simple for new clients to work on other applications, whether it is designed
specifically for purpose or not.
● Use standard HTTP procedure call- outs to retrieve data and requests.
● REST API depends on codes, can use it to synchronize data with a website without any
complications.
● Users can avail access to the same standard objects and data model.
● Brings flexibility formats by serializing data in XML or JSON format.
● Allows Standard-based protection with the use of OAuth protocols to verify your REST
requests.
Disadvantages of REST
● The biggest problem with REST APIs is the nature of multiple endpoints.

● These require clients to do multiple round-trips to get their data.

● REST is lightweight architecture but it is not suitable to handle a complex environment.

● REST requests (especially GET) are not suitable for large amounts of data.

● In a REST API, there is no client request language.clients do not have control over what data
server will return.
● Over-fetching of information is a waste of network and memory resources for both the client
and server.
Thank You!