COMPLETE APIs Crash Course In 14 Minutes [w/ FREE Project] | Vishakha Sadhwani

Main ideas & lessons

• APIs are foundational to how software systems communicate.

  • An API (Application Programming Interface) is a controlled way for a client (website/app/AI agent) to talk to a server (where data and business logic live).
  • Example concept: when Instagram loads a feed, the app requests content from Instagram services via APIs rather than building it locally.

• Understanding APIs is important for both traditional and AI applications.

  • Modern applications are built by connecting many services (payments, maps, authentication, databases, AI models, search, business tools).
  • In AI apps, models typically don’t operate alone—they call APIs to search, retrieve documents, trigger workflows, and take actions.

• The video gives an “API Concepts” and “API architecture patterns” overview, then maps those to AI use cases and infrastructure/framework choices.

---

Methodology / structure presented (detailed)

1) Core API concepts (HTTP + REST-style example)

• APIs communicate using HTTP methods, which specify what action to perform on a resource:

  • GET: retrieve/read data (should not change server state)
  • POST: create new data / submit data for processing
  • PUT / PATCH: update existing data (PATCH is mentioned as “update”)
  • DELETE: remove data

• Typical request structure (REST example):

  • Method: e.g., GET
  • Path:
    • includes the resource (the “resource” is described as “post” in the example)
    • includes a version such as v1
      • Versioning matters because APIs evolve without breaking existing clients
  • Query parameters:
    • filter: narrow results
    • sort: order results
    • pagination: control pagination via page/page-size to avoid returning thousands of records at once
  • Headers:
    • Authorization using Bearer tokens
      • token type described as JWT (JSON Web Token)
      • JWT is said to carry:
        • who the caller is
        • what they’re allowed to do
        • an expiry time
      • server verifies the JWT signature so it doesn’t need to “look up” the user in the database
    • Accept header:
      • specifies desired response format (e.g., JSON)

---

2) Architecture patterns and tradeoffs (what problems they solve)

• REST API

  • Style: most common web API style; “standard”
  • Flow: client sends HTTP request → server returns HTTP response
  • Properties: stateless, resource-oriented
  • Response format: typically JSON
  • Tradeoffs:
    • Simple and widely adopted
    • Can cause overfetching (getting more data than needed) and underfetching (not enough data)
    • Often requires multiple endpoints / round trips to fetch related data

• GraphQL

  • Alternative to REST when clients need flexible data fetching
  • Approach:
    • send one request to a single endpoint
    • request exact fields needed
  • Benefits:
    • avoids overfetching/underfetching
    • response shape matches the query
  • Tradeoffs:
    • gives clients precise control but increases complexity on the server side
    • caching is harder because queries vary
    • poorly designed queries can overload the database

• SOAP

  • Older, more formal enterprise style
  • Uses XML and strict contracts
  • Where it appears: banking, enterprise, telecom, government
  • Tradeoffs:
    • verbose
    • slower to work with
  • Key idea: requests/responses are structured exactly and consistently

• gRPC

  • Uses Protocol Buffers (compact binary) over HTTP/2
  • Often used for internal microservice-to-microservice communication
  • Benefits:
    • exceptional performance
    • strongly typed contracts
  • Tradeoffs:
    • debugging is harder due to binary format
    • less browser-friendly than REST
    • requires more tooling/setup

• WebSockets

  • Keeps a persistent connection open
  • Instead of request/response only, both sides can send messages
  • Use cases: chat, live dashboards, games, streaming updates
  • AI relevance mentioned: token-by-token streaming in chat interfaces often uses WebSocket-like streaming patterns
  • Tradeoffs:
    • real-time, low latency
    • persistent connections consume resources → scalability concerns

• Webhooks (referred to as “WeBooks” in subtitles)

  • Reverses the typical flow
  • Instead of your app polling “did something happen,” an external service calls your API when an event occurs
  • Example events:
    • Stripe calls your server after a payment succeeds
    • GitHub calls your server when code is pushed/passed
  • Properties:
    • event-driven
    • efficient (avoids wasted polling)
    • format often described as HTTP POST with JSON
  • Tradeoffs / requirements:
    • your endpoint must be publicly reachable
    • you must handle retries, failures, and duplicated events carefully

---

3) How APIs are used specifically in AI applications

• In AI apps, APIs are used for three major purposes:

  1. Calling AI models
     • app sends inputs (text/images/audio/structured data) to model API
     • receives generated output
  2. Giving AI access to tools
     • model may decide to call tool APIs such as:
       • search API
       • database API
       • calendar API
       • internal business APIs
  3. Orchestrating workflows
     • AI apps may:
       • make multiple API calls
       • retrieve context
       • call a model
       • validate output
       • call another tool
       • save results
       • return an answer to the user

• OpenAI-compatible / Response-style APIs

  • Mentions OpenAI “Response API” as a recommended interface for new projects
  • Notes OpenAI Standards document REST/streaming/real-time APIs
  • Describes:
    • sending an API key via bearer authentication
    • request includes model name and input
    • response includes generated output plus metadata/usage

• Model Context Protocol (MCP)

  • Motivation: without a standard, tool/data connectors are built from scratch and break when switching model providers
  • MCP is presented as an open standard for connecting AI apps to external tools/data sources
  • Core claim: “build the connector once, use it anywhere that speaks MCP”
  • Workflow described:
    • user → your app → model
    • model requests a tool/context/action mid-generation
    • MCP clients handle these requests via a standardized protocol
    • MCP server sits in front of tools and returns results back into the model context
    • generation continues using that returned context
  • Key components named:
    • MCP client(s)
    • MCP server
    • tools/data sources behind MCP

---

4) API infrastructure layer (how production APIs are protected and operated)

• A raw API endpoint is “just a function on a server,” but in production you typically do not expose it directly.

• API Gateway is placed in front as a middleware layer.

  • Responsibilities:
    • Rate limiting: reject excessive traffic before overwhelming your server (example given: 10,000 requests at once)
    • Authentication/authorization: check API keys and JWT bearer tokens and other credentials
      • ensure users only access what their plan/subscription allows (e.g., Basic user not accessing Pro)
    • Routing: forward requests appropriately
    • Collect logs/metrics:
      • response time
      • error rates
      • token usage per client

• Monitoring and documentation are emphasized as non-optional

  • Monitoring tools mentioned: Grafana, and “Data/Doc/Primith…” style tools (subtitles are noisy, but monitoring is clearly included)
  • Documentation mention: Swagger and OpenAPI tooling

---

5) API frameworks and tools (how to build APIs quickly)

• Flask (Python):

  • lightweight web framework for Python APIs
  • define routes and HTTP methods
  • example described:
    • GET /health returns status
    • POST /summarize receives JSON with a text field and returns a JSON response

• Other frameworks/tools mentioned:

  • FastAPI: popular for modern Python APIs; automatically creates OpenAPI docs
  • Django Rest Framework: common for large Django apps
  • Express.js: widely used for Node.js
  • Spring Boot: Java enterprise
  • .NET: Microsoft environments

• Core build idea reiterated across frameworks:

  • define endpoints
  • accept requests
  • validate inputs
  • run logic
  • return responses

---

6) “What you can build next” (instructional project)

• Mentions a free Coursera Python project for AI application development.
• Intended focus:
  • build an AI-powered web app using Flask and IBM Watson
  • covers:
    • full development life cycle
    • Python modules
    • unit testing
    • best practices
    • routing
    • database/kernel operations (“kernel operations” as stated)
    • deploying to a live server
• The video encourages checking the link below (link not included in subtitles).

---

Sources / speakers featured

• Vishakha Sadhwani (speaker; Senior Solutions Architect; host of the channel/video)
• Instagram (example service used to explain API requests)
• Postman (example tool used to test API requests)
• Stripe (example webhook provider: calls server after payment succeeds)
• GitHub (example webhook provider: calls server on code push/pass)
• OpenAI (mentioned: Response API, OpenAI Standards, OpenAI-compatible APIs)
• Model Context Protocol (MCP) (mentioned as an open standard)
• IBM Watson (mentioned in the recommended Coursera project)
• Tooling mentioned:
  • JWT (JSON Web Token)
  • Swagger / OpenAPI
  • Grafana
  • Flask, FastAPI, Django REST Framework, Express.js, Spring Boot, .NET