%0 Journal Article %1 geiler2018restfull %A Geiler, Manfred %A Spiegl, Thomas %D 2018 %J javamagazin %K json json-api rest-api specification %N 3 %P 80-89 %T RESTfull APIs richtig gemacht %U https://jax.de/blog/software-architecture-design/restful-apis-richtig-gemacht/ %X Der Artikel beschreibt Grundsätze welche man beachten sollte um bessere REST Schnittstellen erstellen zu können.

@article{geiler2018restfull, abstract = {Der Artikel beschreibt Grundsätze welche man beachten sollte um bessere REST Schnittstellen erstellen zu können. }, added-at = {2018-07-29T12:12:56.000+0200}, author = {Geiler, Manfred and Spiegl, Thomas}, biburl = {https://www.bibsonomy.org/bibtex/211f6948d937367904789104ad9bf0524/funthomas424242}, description = {Ohne das der Artikel es explizit herausstellt, wird hier das Vorgehen nur auf Basis der JSON API Spezifikation erklärt, was prinzipiell nicht schlecht wäre. Allerdings wird alles immer so dargestellt als ob es die einzige sinnvolle Möglichkeit wäre. Mir fehlen einfach die Antworten auf das Warum. Obgleich einige Aussagen im Artikel durchaus im Widerspruch zum HATEOAS Vorgehen stehen wird nicht gesagt warum mit der Spezifikation nach XML nun ein weiterer Versuch (diesmal mit JSON) unternommen wird um etwas wie XML SOAP in die Welt zu setzen. Es hat natürlich alles seine Vor- und Nachteile aber auf diese geht der Artikel gar nicht ein. Das Thema wird einfach nicht objektiv betrachtet und der Artikel macht daher den Eindruck als wolle er heimlich wie Schleichwerbung die Verbreitung der JSON API Spezifikation fördern. Wobei die Förderung der JSON API Spezifikation bestimmt sinnvoll ist aber mit solchen Artikel wird ihr halt ein Bärendienst erwiesen. Trotzdem gute Ideen gefunden: * Relationen nicht als Attribute darstellen sondern als Relationen * Teile der Daten von Relationen ruhig mit einbetten wenn es sinnvoll ist aber den Link zur vollständigen Resource mit beilegen. * URL ruhig lesbar aufbauen auch wenn für HATEOAS nicht notwendig. Eine gute Struktur ergibt sich wenn die DB Tabellen Namen (Nomen in Mehrzahl) auf den letzten Teil des URLs gemappt werden und als Liste von Entitäten verstanden werden z.B. localhost/anwendung/personen/ Endpunkt zur Erstellung, Löschung, Aktualisierung und zum Lesen von Instanzen der Klasse Person * Konsequente Fortsetzung der URLs im JSON (So wie Teile von SVG Bildern im DOM referenziert werden können, könnte man auch einzelen Knoten im JSON per URL referenzieren. Beispiel im Artikel: Relationen) }, interhash = {1b6a38e8199a292b6f62127967d29387}, intrahash = {11f6948d937367904789104ad9bf0524}, journal = {javamagazin}, keywords = {json json-api rest-api specification}, language = {Deutschland}, number = 3, pages = {80-89}, timestamp = {2018-07-29T12:37:18.000+0200}, title = {RESTfull APIs richtig gemacht}, url = {https://jax.de/blog/software-architecture-design/restful-apis-richtig-gemacht/}, year = 2018 }