Anatomy of an API

Every API ever shares a common make up. Doesn't matter the language or the environment. What makes them different is, how each one does it and what they build on top if. Let's talk about all those common bits that make up an API.

Server

• The server is responsible for receiving requests and sending responses.
• An API is a Server.This may seem obvious, but really needs to be understood.
• A server is an app that has no visual representation and is always running. Usually connected to a network and shared among many clients (UIs, web apps, mobile apps, other servers, etc).
• Servers usually sit in front of a DB and facilitate access to that DB.
• There are small exceptions here, and that would be Serverless APIs. Big difference with serverless APIs is they are not always on like a traditional server.
• Servers must operate on a port, a virtual place on a computers operating system where network connections start and end. Ports help computers sort out their network traffic. A server must also have an IP address, a unique location used to locate a server on a network, like the internet.
• An IP address helps traffic go to and from a specific device whereas a port allows targeting of specific services or apps on a device.
• An example would look like this: 127.0.0.1:5000. Where 5000 is the port and the rest is the IP address.

Route

A route is a unique combination of a URL path and a HTTP Method. Routes are used to locate certain resources or trigger certain actions on an API.

HTTP Methods or Verbs are constants that are used by API developers and HTTP to help determine intent of an API call. There are many methods, but the common ones are:

Method	Description
GET	Retrieve data - used to get information from an API
POST	Create data - used to mutate or create new information on an API. Usually has data sent along with the request.
PUT	Update data - used to replace existing information on an API. Usually has data sent along with the request.
PATCH	Update data - used to update existing information on an API. Usually has data sent along with the request.
DELETE	Delete data - used to remove existing information on an API.
OPTIONS	used with CORS by browsers to check to see if the client is able to actually communicate with an API

Here are some examples of routes:

GET / api / user / 1;
POST / food;

REST

Engineers can design these routes and what the routes actually do however they see fit. To standardize this, there are different approaches to designing these routes.
The most popular is REST(Representational State Transfer). There are others like grpc, graphql, and protobuff.

Route Handlers

A route handler is a function that executes when a certain route is triggered from an incoming request. Depending on the API design and intent of the request, the handler will interact with the database. Looking at our route examples above:

• A route handler is this, this callback right here.That's a route handler.
• It's just a function that responds to an event just like a handler for a click event or a hover event.That's basically what it is.
• Typically what you do in a route handlers,this is where you would talk to the database.
• This is where all the magic happens.This is the thing you're trying to protect is the route handler.

import http from "http";
const server = http.createServer((req, res) => {
  if (req.url === "/" && req.method === "GET") {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.write(JSON.stringify({ message: "hello" }));

    res.end();
    return;
  }

  res.writeHead(404, { "Content-Type": "application/json" });
  res.end(JSON.stringify({ message: "nope" }));
});

const PORT = process.env.PORT;

server.listen(PORT, () => {
  console.log(`server on ${PORT}`);
});

Method	Request URL	Description
GET	/api/user/1	If this API was a REST API, the route handler would query the database for a user with the ID of 1.
POST	/food	If this API was a REST API, the route handler would create a new food in the database, using the data sent along with the request.

why you have a server in the first place?

• So the server needs to be able to respond to all of us. and that's how it does it by having
• a route handler responding to each and one of our individual requests.