25.0110 Gdrive

This page lists the main concepts (tools/libraries) for

• 1.1 APIs. Create API
  • 1.1.1 Without framework
  • 1.1.2 With framework
  • 1.1.3 Using deploy platform
• 1.2 API-docs
  • Create REST Swagger
    • 1.2.1 Manually
    • 1.2.2 From annotations
    • 1.2.3 Using autogen
  • 1.2.4 Publish REST API-docs (Postman, Sphinx)
  • 1.2.5 GraphQL (REST endpoint aggregator)

---

• 1.3 HTTP/REST API evolution
• (1.4 Non-HTTP)
  • 1.4.1 gRPC
  • 1.4.2 Websocket
  • 1.4.3 Socket.io
  • 1.4.4 MQTT
• (1.5 Other topics (aggregator ch4, mocking?))

• ASTRO
• HONO
• DJANGO
• NEXTJS
• NESTJS
• NODEJS , express
• FLASK
• FASTAPI
• ANGULAR

---

24.1228

The following (WIP) is a conceptual overview of the historical development of APIs (I will gradually how API docs and tools developed during each stage).

• 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)

In the beginning there were dumb terminals and mainframes.

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

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

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).

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).

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

(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).