Goals and concepts - terrytaylorbonn/auxdrone GitHub Wiki

24.1228

The following is my own conceptual overview (WIP) of the historical development of APIs.

• 1 Terminal (client) and mainframe (server)
• 2 PC screen (no windows) to mainframe
• 3 PC browser via HTTP to webserver
• 4 Client/server "REST" APIs
• 5 Client/server adds state
• 6 The client adds windows
• 7 GraphQL (vs REST)

1 Terminal (client) and mainframe (server)

In the beginning there were dumb terminals and mainframes.

2 PC screen (no windows) to mainframe

The first PCs had just a text screen (no windows). You'd run a terminal program to access a mainframe.

3 PC browser via HTTP to webserver

The web browser was basically a PC within a PC that could easily link to a webserver using HTTP.

4 Client/server "REST" APIs

The web client/browser/HTTP concept was then used as the basis for "REST" APIs that connected PC client frontends to server backends (for some reason all intros to this topic start with a ridiculously complicated discussion of "REpresentational State Transfer" concepts that no reader understands).

5 Client/server adds state

REST APis were great because they were simple and perfect for viewing web pages. But as those pages because apps, it became important to maintain state while moving between pages, which spawned the dev of tools such as React (see the MERN stack demo in Deployment history).

6 The client adds windows

Eventually client web apps needed windows, separate areas within the browser that were independent of each other (just like windows).

7 GraphQL (vs REST)

(I will add GraphQL to this wiki in the future). The problem with REST APIs is that you cant specify exactly what info you want to send/receive to/from an endpoint. With GraphQL you specify exact what you want. The GraphQL Apollo Server interacts with the backend with traditional REST API (at least this is my best guess of how it works; dont expect to get such a clear explanation anywhere from the GraphQL website).