Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Exploring Swagger UI and the API Documentation

Exploring Swagger UI and the API Documentation

~12 Min. Lesezeit Zuletzt aktualisiert am August 8, 2026

API Platform AUTOMATICALLY generates COMPLETE, interactive API documentation – no separate tool, no manually maintained documentation files needed.

Opening Swagger UI

open https://localhost/api/docs
# or just visit it in the browser

EVERY endpoint we've built so far (/api/greeting from chapter 5) AUTOMATICALLY appears here – including a description, expected parameters, and example responses.

Testing an endpoint DIRECTLY in Swagger UI

Click an endpoint, then "Try it out" – Swagger UI performs the ACTUAL HTTP call, EXACTLY like curl, but without a terminal. Useful for quick, EXPLORATORY tests while working on a new resource.

The raw OpenAPI specification

curl -k https://localhost/api/docs.json

Swagger UI is ultimately just a VISUAL representation of this JSON specification – chapter 80 uses EXACTLY this file to automatically generate TypeScript types for our React frontend, instead of maintaining them manually.

Two documentation formats: Hydra and OpenAPI

FormatPurpose
OpenAPI (Swagger UI)The industry-standard format for REST APIs – understood by MOST tools/libraries, EXACTLY the format from this chapter.
HydraAn additional, semantic format (part of JSON-LD) enabling "self-describing" APIs – less relevant for our React frontend, but part of API Platform's default output.

Adding custom descriptions

#[ApiResource(
    description: 'Manages projects in the task manager.',
    operations: [
        new Get(description: 'Fetches a single project by its ID.'),
    ],
)]
class Project
{
    // ...
}

description at both the resource AND operation level appears DIRECTLY in Swagger UI – a small effort that considerably eases later collaboration (e.g. with the React team consuming the API without reading your PHP code).

Tipp: Rule of thumb: describe AT LEAST resources and operations whose behavior ISN'T immediately obvious from the name – a GET /projects/{id} needs no explanation, a custom endpoint like POST /tasks/{id}/complete (chapter 61) definitely does.