{"id":2118,"date":"2025-02-09T16:33:55","date_gmt":"2025-02-09T16:33:55","guid":{"rendered":"https:\/\/avant-iconic.com\/?p=2118"},"modified":"2025-03-01T20:27:54","modified_gmt":"2025-03-01T20:27:54","slug":"rest-anti-pattern","status":"publish","type":"post","link":"https:\/\/avant-iconic.com\/en\/rest-anti-pattern\/","title":{"rendered":"Ist REST jetzt ein Anti-Pattern?"},"content":{"rendered":"

REST-APIs sind schon seit mehr als einem Jahrzehnt allgegenw\u00e4rtig. Doch nicht jeder wei\u00df, dass das, was heute meist als „REST“ bezeichnet wird, gar nicht die urspr\u00fcngliche Idee war. REST wurde von Roy Fielding in seiner Dissertation<\/a> als „Representational State Transfer“ entwickelt und eine wichtige Idee darin war HATEOAS (Hypertext as the Engine of Application State), was im Grunde bedeutet, dass jede API-Antwort Navigationslinks zu anderen parametrisierten REST-Endpunkten enth\u00e4lt, zum Beispiel Detail-Links bei einem Listen-Endpunkt. Man kann in der API also \u00e4hnlich navigieren, wie das auf einer HTML-Seite m\u00f6glich w\u00e4re.<\/p>\n\n\n\n

Das hat sich aber in der Praxis kaum durchgesetzt. Wenn wir im Folgenden von „REST in der Praxis“ sprechen, meinen wir daher etwas anderes, n\u00e4mlich REST im Maturity Level 2<\/a> mit JSON \u00fcber HTTP, ohne HATEOAS, daf\u00fcr mit OpenAPI oder einer \u00e4hnlichen Dokumentation. Das ist zwar eine sehr enge Definition, die wenig mit dem Original zu tun hat, spiegelt jedoch den Industrie-Standard sehr gut wieder, wie wir finden. Und da Software in erster Linie dazu da ist, um benutzt zu werden, lohnt es sich in der Regel, Industrie-Standards auch in Erw\u00e4gung zu ziehen.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Diese Industrie-Standard-Form von REST wird aber immer wieder kritisiert<\/a>. Dabei handle es sich lediglich um eine Form von CRUD, was ja sowieso ein Anti-Pattern sei. Diese Aussage meint aber nicht, wie man vielleicht denken k\u00f6nnte, dass CRUD-Datenbanken <\/em>problematisch sind. Im verlinkten Video<\/a> wird lediglich problematisiert, dass die CRUD-Datenbanklogik auf die Backend-Ebene gehoben wird. Und, das ist f\u00fcr einige vielleicht \u00fcberraschend, finden wir in der Regel auch nicht gut!<\/p>\n\n\n\n

Wie h\u00e4ngt REST mit CRUD zusammen?<\/h3><\/div>\n\n\n\n

Die HTTP-Methoden GET<\/code>, POST<\/code>, PUT<\/code>, PATCH<\/code> und DELETE<\/code>, die bei allen Formen von REST zum Einsatz kommen, sind tats\u00e4chlich sehr CRUD-nah. Aber: Niemand sagt, dass dieses CRUD auf derselben Abstraktionsebene wie die Datenbank sein muss. Ein POST-Endpoint, der einen Kunden erfasst, k\u00f6nnte im Hintergrund zehn verschiedene Datenbanktabellen bef\u00fcllen und einen Domain-Event ausl\u00f6sen und das alles sauber abstrahieren.<\/p>\n\n\n\n

Wer REST nur als CRUD-Interface in die Datenbank sieht, der l\u00e4sst REST potenziell hinter seinen M\u00f6glichkeiten zur\u00fcck und kreiert dar\u00fcber hinaus eine API, wo Datenfilterung und -verbindung, eigentlich eine St\u00e4rke von Datenbanken und Backends, im Frontend erledigt werden muss. Das ist \u00fcbrigens keine Wertung; genauso haben wir es in einem Projekt mit umfangreichen Offline-F\u00e4higkeiten schon gehandhabt. Der Regelfall ist es aber nicht.<\/p>\n\n\n\n

Die Tendenz, einer Datenbank einfach eine API \u00fcberzust\u00fclpen, gibt es tats\u00e4chlich, und diese ist nur in einem Fall eine gute Idee: Die Datenbank soll als eine Art DBaaS (Database as a Service) dienen. So war es auch in unserem Projekt. In allen anderen F\u00e4llen ist das einfach nur eine Fehlentscheidung, die man zwar kompensieren kann, aber in der Regel nur auf Kosten von hoher Komplexit\u00e4t und schlechter Performance.<\/p>\n\n\n\n

Fachliches REST<\/h2><\/div>\n\n\n\n

Wir gehen daher mit Herrn Roden aus dem Video insofern \u00fcberein, dass eine API in der Regel fachliche Operationen anbieten sollte. Auch die Vorbereitung der Operationen auf CQRS, also eine Trennung von Schreib- und Leseoperationen, sehen wir als sinnvoll an. So muss man bei einer Skalierung, die eines Tages notwendig werden k\u00f6nnte, die externe API nicht umstellen.<\/p>\n\n\n\n

Nun gibt es aber eine wichtige Nuance, die oft zu kurz kommt: Die meisten fachlichen Operationen einer API lassen sich sehr gut ins CRUD-Schema von GET, POST, PUT, PATCH und DELETE einreihen. Einige jedoch \u00fcberhaupt nicht. Was ist die pragmatische L\u00f6sung? Wir finden, alles, was ins Schema passt, sollte dort eingereiht werden, was nicht passt, sollte zu einem POST werden. Der Name der Operation wandert in die OpenAPI-Operation-ID<\/a>. Dadurch ergeben sich etwa folgende Endpunkte:<\/p>\n\n\n\n