A browser can open an API URL, but curl lets you see the request and response more closely. In this lesson you will start a small local server, fetch a JSON response, inspect its headers and send a JSON body. You need Python 3 and curl installed. The server is deliberately small and runs only on your own computer.

Create a file called server.py with the following code:

from http.server import BaseHTTPRequestHandler, HTTPServer
import json

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        body = json.dumps({"name": "tea", "id": 1}).encode()
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(body)

    def do_POST(self):
        body = self.rfile.read(int(self.headers.get("Content-Length", 0)))
        try:
            data = json.loads(body)
        except ValueError:
            self.send_error(400)
            return
        result = json.dumps({"received": data}).encode()
        self.send_response(201)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(result)

HTTPServer(("127.0.0.1", 18766), Handler).serve_forever()

Run python3 server.py in a terminal and leave it running. Open another terminal for the curl commands below. The address 127.0.0.1 points to your own machine. This toy service returns the same item for any GET path and echoes JSON sent to any POST path; it does not save anything.

Cloudflare just published the results of an experiment that every API developer should read, even if you’ll never run a firewall. The company put frontier AI models inside a test harness and told them to get past its own Web Application Firewall.

They found gaps. Not many, but the pattern of what got through is the real lesson.

What Cloudflare did

The test started with attack payloads the WAF already blocked. Instead of replaying a fixed list, the models looked at how each attempt was handled and proposed a tweak for the next one: different encoding, different placement in the request, different delivery. They had no access to the WAF rules or source code. Pure black box.

Istio 1.31 is out, and one line in the release notes says a lot about where API infrastructure is heading. You can now run agentgateway, a proxy built for AI agent and MCP traffic, as a waypoint inside the mesh.

If “waypoint” means nothing to you yet, that’s fine. Here’s the short version, then why it matters if you build APIs.

What changed in 1.31

Istio’s ambient mode splits the mesh in two. A small per-node component handles encryption and basic connectivity. Anything that needs to understand HTTP, like routing, auth policy or rate limits, goes through a separate proxy called a waypoint. You opt services into a waypoint with a label.

OpenAI’s DevDay last week was mostly pitched as an agents event. Persistent agents, cloud Codex, a cheaper model. Fine. But if you’re learning to build and design APIs, two of the smaller releases are worth more of your attention than the headline model, because they say a lot about where API contracts are going.

Here’s what shipped, then what to take from it.

What OpenAI released

The Agents API is now in public beta. It runs agents on OpenAI’s own infrastructure, with memory, tool calling, tool search, context compaction and multi-agent support carried over from Codex. The new piece is computer use: an agent can now drive software through its graphical interface, clicking and typing the way a person would.

Every few weeks someone asks whether MCP replaces REST. It does not. The question is still worth answering carefully, because the line between the two moved in July, and most of the explanations written before then are now describing a protocol that no longer exists.

An HTTP API is a contract between two pieces of software written by people who read documentation. A developer opens the reference, learns that POST /v1/invoices wants a customer ID and an array of line items, writes the call, and ships it. The knowledge lived in a human head at build time and then got frozen into source code. When the endpoint changes, something breaks in production and a person goes and fixes it.

Sixty-six sites, 18,880 visits and 19,950 page views for the week of August 30 to September 5. Visits rose 14.91% and page views 17.01%, which is a good week by any reading of the top line. The median page load time across the network went the other way, climbing 28.64% to 3,579ms, and that single figure complicates the rest of the report.

technologies.org led again with 2.44k visits and 2.52k page views, up 74.29% and 76.22% respectively, on a load time of 2,561ms (up 8.8%). Chrome accounted for 1.32k of those sessions against 1.05k logged as Unknown, with a further 30 from ChromeMobileWebview. Its LCP at the 75th percentile improved by a third to 2,704ms even as the raw load time crept up, so the main content is painting faster while the tail of the load stretches out. CLS came in at 1, up 262.32%, and INP at 40ms. In second place, marketresearchmedia.com posted 1.17k visits and 1.17k page views, both up 265.62%, making it the largest mover in the report and also its worst performer on speed: load time nearly tripled to 7,454ms and the 75th percentile LCP went up almost fivefold to 4,988ms. Chrome carried 1.02k of those sessions, Unknown 110, ChromeMobile 10. Visits and page views are identical, so every session ended on the page it began on. Third, analysis.org held steady at 1.1k visits (up 8.91%) and 1.12k page views (up 9.8%), and delivered the clearest genuine improvement in the report with a load time down 21.99% to 3,579ms after weeks in five figures. Its LCP eased 10.42% to 3,680ms, CLS sat flat at 1, INP at 40ms. Unusually for the top three, Unknown outnumbered Chrome here, 660 to 390, with 20 on ChromeMobile.

Authentication is where most API integrations go wrong the first time. Not because the concepts are complicated, but because there are several distinct mechanisms in common use, they solve different problems, and developers often reach for the one they recognize rather than the one that fits. Understanding what each mechanism actually does — and what it does not do — is the difference between an integration that works and one that works until it doesn’t.

Every API feature eventually reaches the end of its useful life. The endpoint was designed before the domain was understood. The schema made assumptions that no longer hold. A better approach exists. The old version must go. How you handle that retirement determines whether your API’s integrators trust you or resent you.

Deprecation done well is a communication and scheduling problem. Deprecation done poorly is a breaking change that happens without warning.

Errors are not edge cases in API development. They are a primary output. Every API call that can fail will fail — due to invalid input, authentication problems, resource conflicts, rate limits, or infrastructure issues — and how an API communicates those failures determines whether integrators can handle them gracefully or are left guessing. An API that returns clear, consistent, actionable errors is a well-designed API. Everything else is guesswork at scale.

An API gateway is a server that sits between clients and backend services, acting as the single entry point through which all API traffic passes. Every request goes through the gateway, which can inspect, modify, authenticate, route, transform, and rate-limit that traffic before it reaches any backend service. For teams running multiple services, an API gateway centralizes concerns that would otherwise be duplicated across every service independently.

Understanding what a gateway provides — and what it does not — is the prerequisite to deciding whether one belongs in your architecture.