Seite 4: Fazit und Ausblick

Inhaltsverzeichnis

Es gibt viele Alternativen zu HAL, die nach Meinung der Autoren alle nach zu viel "geschwätziger" Kontrolle über das finale Ausgabeformat greifen (siehe Siren, UBER, Collection+JSON) und dann letztlich nicht so viel Mehrwert bieten.

Bei HAL bleibt der Kern der Ressource bestehen und lässt sich nach Belieben erweitern. Alle URI-Änderungen passieren hinter den Kulissen und solange die Relationen und ihre Semantik bestehen bleiben, muss clientseitig nichts angepasst werden. Und dort, wo Änderungen nicht vermeidbar waren, ließ sich die Deprecation-Information auf einem Standard HAL-Attribut mitteilen und die Relation später entfernen. Theoretisch hätten die API-Clients niemals URIs selbst erstellen oder manipulieren müssen und somit einen häufigen Fehler vermeiden können.

Die größte Hürde beim Einsatz von HAL ist sicherlich organisatorischer Natur, denn HAL ist nichts weiter als eine Konvention und hängt allein vom Commitment der Leute im Projekt ab. Denn es verlangt nach viel Disziplin der Entwickler, nicht von den HAL-Konzepten abzuweichen und nach Abkürzungen zu suchen. Diese Herausforderung zeigte sich zu Projektanfang und auch später bei personellen Wechseln, allerdings ist die Lernkurve flach und das Design der API gut verständlich. HAL ist sicherlich nicht perfekt für REST-APIs, jedoch fanden sich immer Wege, es zu erweitern, ohne dass die vielen Vorteile oder das grundsätzliche Konzept von HAL verloren gingen.

Dirk Lingstädt
ist Senior Consultant bei INNOQ. Nach Ausflügen ins Projektmanagement und in die kreative Frontend-Welt, fühlt er sich mittlerweile in der Backend-Entwicklung am wohlsten. Aktuelle Lieblingsthemen sind RESTful APIs, DDD, Spring Boot und Elasticsearch.

Dr. Leonardo Ramirez
arbeitet als Senior Consultant und Entwickler bei INNOQ. Seine inhaltlichen Schwerpunkte liegen auf den Themen Mensch-Computer-Interaktion, User Experience und Frontend Technologies. (mdo)