Admin API¶

Aktuální a deklarované endpointy¶

V app/routes/admin.php jsou dnes definované tyto endpointy:

Products¶

• GET /admin/v1/products
• GET /admin/v1/products/{id}
• POST /admin/v1/products
• PATCH /admin/v1/products/{id}
• POST /admin/v1/products/{id}/publish
• POST /admin/v1/products/{id}/unpublish

Categories¶

• GET /admin/v1/categories
• POST /admin/v1/categories
• PATCH /admin/v1/categories/{id}
• DELETE /admin/v1/categories/{id}

Brands¶

• GET /admin/v1/brands
• POST /admin/v1/brands
• PATCH /admin/v1/brands/{id}

Co je reálně implementováno¶

Podle aktuálního kódu jsou dnes implementovány tyto controllery:

• ProductController
• CategoryController
• BrandController

Admin API tedy dnes reálně obsluhuje:

• listing a detail produktů napříč workflow stavy,
• vytvoření produktu a jeho základní editaci,
• publikaci a stažení produktu zpět do draftu,
• listing kategorií a jejich vytvoření, editaci a smazání,
• listing značek a jejich vytvoření a editaci.

Response format¶

API vrací JSON v konzistentním tvaru:

{ "data": [...] }

{ "data": {...} }

{ "error": "Not found" }

U listingů je navíc meta s paginací.

DELETE /admin/v1/categories/{id} vrací 204 No Content.

Parametry a workflow¶

Products¶

• GET /admin/v1/products
• locale, výchozí cs
• page, výchozí 1
• limit, výchozí 20, maximum 100
• status, nepovinný filtr
• GET /admin/v1/products/{id}
• locale, výchozí cs
• POST /admin/v1/products
• vyžaduje code, brand_id
• podporuje ean, is_clearance, publication_status
• umí rovnou zapsat translation a slug
• PATCH /admin/v1/products/{id}
• podporuje změnu ean, brand_id, is_clearance, new_until, hide_until
• umí zapsat translation a slug
• POST /admin/v1/products/{id}/publish
• přepne publication_status na published
• POST /admin/v1/products/{id}/unpublish
• přepne publication_status na draft

Povolené workflow stavy v controlleru jsou:

• draft
• published
• hidden
• blocked
• discontinued
• deleted

Categories¶

• GET /admin/v1/categories
• locale, výchozí cs
• page, výchozí 1
• limit, výchozí 200, maximum 500
• POST /admin/v1/categories
• vyžaduje code
• podporuje parent_id, is_active, translation
• PATCH /admin/v1/categories/{id}
• podporuje code, sort_order, is_active, is_internal, translation
• DELETE /admin/v1/categories/{id}
• respektuje databázové vazby
• při navázaných produktech vrací 409 Category has assigned products, unassign them first

Brands¶

• GET /admin/v1/brands
• locale, výchozí cs
• page, výchozí 1
• limit, výchozí 50, maximum 200
• POST /admin/v1/brands
• vyžaduje name, slug
• podporuje website, logo, is_local, translation
• PATCH /admin/v1/brands/{id}
• podporuje name, slug, website, logo, is_local, translation

Při kolizi unikátního slugu vrací brand endpointy 409 slug already exists.

Jak admin chápat architektonicky¶

V prvním kroku dává smysl, aby Products Admin byl součástí stejné aplikace jako public katalogové API.

To prakticky znamená:

• public API je primárně read API,
• admin API je write API,
• admin nezapisuje přímo "bokem" mimo pravidla,
• admin nemusí používat public API jako mezivrstvu.

Správný směr je společná aplikační logika nad jedním modelem, ne dva oddělené systémy, které si mezi sebou jen přeposílají requesty.

Očekávaná odpovědnost admin vrstvy¶

• zápis a editace produktu,
• publikační workflow,
• správa kategorií a jejich stromu,
• správa značek,
• návazně později pricing, inventory, média a importní operace.

Důležitá omezení současné implementace¶

• admin vrstva dnes zapisuje hlavně catalog a translation data, ne plný pricing nebo inventory model,
• produkty, kategorie i značky validují UUID na detailových a write endpointch,
• zápisy běží v transakcích a audit log se zapisuje přes repository,
• publish a unpublish dnes řeší jen změnu stavu, ne širší publikační pipeline,
• autentizace je zapojená v middleware pipeline, ale detail jejího napojení popisuje spíš aplikace než tato stránka.