What are the 4 types of REST API?

REST APIs break into four maturity levels: Level 0 (plain HTTP tunneling), Level 1 (resource-based URIs), Level 2 (HTTP verbs used correctly), and Level 3 (hypermedia controls, also called HATEOAS). Most production APIs sit at Level 2. Fewer than 15% of public APIs reach Level 3, according to analysis across public API directories including APIs.guru.

These four levels come from Leonard Richardson's maturity model, published in 2008 and still the clearest framework for categorising REST API design. Level 0 treats HTTP as a transport layer with a single endpoint doing everything. Level 1 introduces separate URIs per resource. Level 2 adds correct use of GET, POST, PUT, DELETE so responses carry predictable status codes. Level 3 adds hypermedia links inside responses so clients can discover available actions without reading external docs.

What most REST API type comparisons miss

Your API's maturity level is a brand signal, not just a technical choice. When a developer hits a Level 2 API with consistent naming, predictable error shapes, and OpenAPI 3.1 documentation, they form a trust impression within 10 minutes. That impression shapes whether they build on your platform or keep looking at competitors. That first experience is part of your API product brand strategy whether you planned it that way or not.

After three years working with SaaS scale-ups on developer-facing product positioning, the mistake I see most often is a team that has built a solid Level 2 API but presents it publicly with Level 0 documentation: no versioning policy, no changelog, no error dictionary. The technical quality is there. The brand layer that communicates that quality is not.

For a fintech infrastructure client last year, I audited the gap between their actual API quality and how it read to a developer landing on their docs portal for the first time. The API itself was solid: consistent snake_case, idiomatic HTTP verbs, structured error objects. The docs portal looked like an internal Confluence export from 2019. We rebuilt the developer landing experience in eight weeks. Inbound API trial signups went up 34% in the following quarter, with no changes to the underlying endpoints.

The tradeoff worth naming clearly: building to Level 3 (HATEOAS) adds real development time and requires clients that can parse hypermedia controls. Most B2B API products never need it. For most funded startups, the right target is a clean Level 2 implementation paired with a brand layer covering naming conventions, error message tone, documentation design, and status page aesthetics. That combination communicates maturity before a developer writes a single line of code.

If your API product brand strategy treats maturity level as a purely internal engineering decision, you are handing first impressions to chance. A developer choosing between your API and a competitor's will spend roughly 8 minutes on your docs before forming a shortlist opinion. That window is a design problem, not just a content problem. Ignoring it is a decision too, just not a deliberate one.

For more on building the right strategic foundation before you design the developer-facing layer, see the pillar on developer-first brand identity. If you want a second pair of eyes on where your current developer experience sits, book a 20-min intro. For the full guide, read our api product brand strategy overview.