JavaScript Fetching External Data

REST

So we now know that JavaScript gives us the option of receiving and sending data, but what kind of data do we receive? What should we send? Where do we send the data?

Roy Thomas Fielding presented an architectural style for distributed hypermedia systems in his dissertation in the year 2000 that he called the REST architecture. The REST architecture has over time become the defacto standard of web service APIs, and it is highly probable that whatever API we need to use provides a RESTful interface.

Guiding principles

In order for an interface to be classified as RESTful, it needs to follow six main guiding principles:

1. Client-server: Client concerns (the web site in our case) must be separated from server concerns. By doing this we don't tie our server logic to a specific client type, and make it easier to create clients for other platforms. This also simplifies the server logic.
2. Stateless: Every request from the client to the server must start with a completely blank sheet. The server must be able to retrieve all necessary information based on that single request. This often simplifies server logic, but can make the client's job harder.
3. Cacheable: The server can tag a response as cacheable, which gives the client the right to reuse that specific response's data for later, equivalent requests.
4. Uniform interface: The server must provide a uniform interface that all exported components in the system use such that all interactions with the server follow the same pattern. To achieve this goal of a uniform interface, REST is defined by four interface constraints:
   1. Identification of resources
   2. Manipulation of resources through representations
   3. Self-descriptive messages
   4. Hypermedia as the engine of application state
5. Layered system: Server components must be layered in a way where they are cannot be allowed to be aware of other layers beyond the immediate layer with which they are interacting. This guideline sets a an upper bound on overall system complexity and makes individual components more independent.
6. Code on demand (optional): The server can provide the client code-on-demand which the client then can execute. This allows for lighter initial payloads and after that only a load and execution of code that client explicitly needs.

Resources

The primary data representation, in REST, is called a resource. In general, all pieces of information that can be named can be a resource. This includes text, images, services, a collection of other resources, physical object, etc.

A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

-- Roy Fielding (5.2.1.1 Resources and Resource Identifiers)

We can have a collection of a resource, but singletons are also allowed. Resources can be divided up into hierarchy.

Paths

REST APIs use Uniform Resource Identifiers (URIs) to unambiguously identifiy resources.

Methods

One of the REST guidelines specify that the server must provide a uniform interface. We have established that information must be divided into resources, which naturally leads us to the conclusion that the server must provide a uniform interface which clients can use to get, modify and delete resources.

Typically, RESTful HTTP APIs give the same meaning to some HTTP methods:

• GET: Used to fetch resources
• POST: Used to create resources
• PUT: Used to modify resources
• PATCH: Used to modify parts of resources
• DELETE: Used to delete resources