REST-API Definition

[SemikolonDEV]

Für die einfache Generierung eines REST-API Clients in jeglicher Programmiersprache wäre es sinnvoll die Schnittstellendefinition in als OpenAPI in der YAML- oder JSON- Syntax bereitzustellen.

[marvger]

Das wäre wirklich praktisch - ist das in (naher) Zukunft geplant?

[abrain]

Die API unter /wp-json/ dokumentiert sich eigentlich bereits selbst, und das dynamisch zur Laufzeit, je nach installierten Plugins und Settings. Allerdings nicht im OpenAPI-Format, es scheint aber Konverter dafür zu geben (z.B. https://wordpress.org/plugins/wp-openapi/). Sieht das brauchbar aus?

[marvger]

Stimmt.. gar nicht dran gedacht.. :) Danke dir!
Allerdings gibt es nur eine POST-Route und keine zum Updaten, Holen (einzeln und alle) und Löschen.

Vorschlag fürs nächste Update: CRUD-Routen?

[abrain]

Im Namespace einsatzverwaltung gibt es nur diese eine Route, ja. Das ist auch bisher die einzige selbst definierte.

WordPress generiert für alle Inhaltstypen und Taxonomien automatisch CRUD-Routen unter /wp-json/wp/v2/, sofern man das nicht unterbindet. Für die Einsatzberichte also beispielsweise /wp-json/wp/v2/einsatz. Entsprechend schien es mir nicht sinnvoll, eine eigene Reihe von API-Endpunkten parallel zu pflegen.

Das Problem mit den automatisch generierten Routen ist allerdings, dass sie direkt das interne Datenmodell widerspiegeln. Und sobald sich daran etwas ändert, genau genommen auch die API-Kompatibilität bricht. Aus diesem Grund entstand der POST-Endpunkt, um eine stabile Schnittstelle zu haben, die auch über interne Veränderungen hinaus funktioniert. Außerdem wäre das Anlegen eines Berichts mit nur einem einzigen Aufruf über die anderen Endpunkte IIRC so gar nicht möglich, da erst IDs von Taxonomien abgefragt werden müssten.

Bei den automatisch generierten Routen ist es aktuell aber tatsächlich noch so, dass einige Metadaten wie z.B. der Einsatzort fehlen. Das war eine Vorsichtsmaßnahme, da die REST-API von WordPress erst einmal öffentlich lesbar ist. Also wenn der Ort eingetragen ist, aber über das Template nicht ausgegeben wird, hätte man ihn dort trotzdem nachlesen können. Das lässt sich aber soweit ich mich erinnere recht feingranular definieren, dass einzelne Eigenschaften nur mit Authentifizierung lesbar sind (schreibbar sowieso). Muss ich mir nochmal ansehen.

Die automatisch generierten Routen folgen aber einem Standardschema, und da gibt es schon Client-Libraries dazu (die ich aber auch noch nicht verwendet habe): https://developer.wordpress.org/rest-api/