How Interfaces work

Before you start

• Requirements

  Estimates and APIs start from an agreed list of what the system must do.

  Open lesson

Why it matters

A shortener has two callers with different outcomes: an owner creates a code, and a visitor opens it. Alias conflicts, missing codes, and expired links must be unambiguous before components are chosen, or hidden work appears on the busiest call. The contract must keep each redirect to one lookup, with no join, while preserving unique aliases and expiry.

Create a short link and redirect a visitor. Custom aliases are unique. Links can expire.

For alias “docs,” define POST /links as a 201-or-409 write and GET /docs as a 301-or-404 read, then key one mapping row by code so the visitor’s redirect never joins another table.

POST /links accepts the long URL and optional alias. It returns 201 with the chosen code, or 409 when “docs” is already taken. GET /docs returns 301 with a Location header; an unknown or expired code returns 404.

The links row is keyed by code and stores long_url, owner_id, created_at, and expires_at. The same uniqueness rule covers generated codes and aliases. Click counts do not belong on this row because updating them would turn the redirect’s indexed read into a contended write.