REST API HATEOAS welches Format verwenden

[Marco H. (damarco)]

Hallo,

ich bin gerade dabei meine REST API hypermedia links hinzuzufügen.

Nun bin ich mir nicht sicher welches Format ich dafür verwenden soll ?


https://tools.ietf.org/html/draft-kelly-json-hal-08 ?
https://github.com/kevinswiber/siren ?


oder gar was ganz anderes ?

Ich habe mich mit HAL schon ausprobiert. An sich komme ich damit klar 
und ich kann mit dem HAL Browser durch meine Ressourcen bewegen. 
Nachteil an HAL ist das man die Methoden auf eine Ressource nicht 
abbilden kann.

Man geht immer von GET aus, so muss man mit  OPTIONS sich erst 
vorfühlen...

Siren ist feiner strukturiert, ausprobiert habe ich das noch nicht...

So recht weiß ich nicht welche Richtung ich einschlagen soll ? Ich habe 
echt keine Ahnung???

Dann die nächste blöde Frage, muss man bei den Methoden POST,PUT 
unbedingt json verwenden ? Momentan läuft das über 
application/x-www-form-urlencoded, als Antwort kommt json zurück.

Aus der Betrachtung wäre Json natürlich erst mal besser da man die 
values einfach ändert und per PUT zurück sendet. Aus Sicht der 
Geschwindigkeit etc. er weniger, da es auf Hardware läuft die nicht 
üppig damit bestückt ist.

Es wird auch so kommen, aber momentan habe ich an anderen ecken mehr zu 
tun. Es funktioniert mit den Forms ja erst mal ganz gut.

[Marco H. (damarco)]

Hallo..

ich habe mir die Frage mal wieder selbst beantwortet...

Ich habe das jetzt mit HAL 
https://tools.ietf.org/html/draft-kelly-json-hal-08 umgesetzt.

Nun ergeben sich noch einige Fragen...

Die Methode lässt sich mit HAL nicht abbilden und hierzu gibt es mehrere 
Abwandelung die das versuchen zu beheben.

Ich habe mich dazu entschieden mit der Option profile 
https://tools.ietf.org/html/draft-kelly-json-hal-08#ref-I-D.wilde-profile-link 
auf ein json Schema zu verweisen welches die Ressource beschreibt. Hier 
ließen sich auch die Methode und die Parameter beschreiben.

Die Frage ist eben mach ich das so richtig ?

Auf der Client Seite würde ich vielleicht dann json Forms verwenden, um 
die UI Elemente zu rendern. https://jsonforms.io/

Ich habe das noch nie gemacht ;) Vielleicht kann mir jemand ein paar 
Tipps geben wie solch eine API entwirft oder auch nicht... Mein Problem 
ist eben auch das es da zu viele Möglichkeiten gibt und ich nur schwer 
abschätzen kann welche Weg der richtig ist. Ich habe mir schon ein paar 
APIs angesehen ;).


Ich hänge mal ein paar json dran.. Ich habe den HAL Browser verwendet um 
die json zu test.. https://github.com/mikekelly/hal-browser


Ich hoffe mir kann jemand behilflich sein :).

[Sklavenvermittler (Gast)]

Marco H. schrieb:

> Aus der Betrachtung wäre Json natürlich erst mal besser da man die
> values einfach ändert und per PUT zurück sendet. Aus Sicht der
> Geschwindigkeit etc. er weniger, da es auf Hardware läuft die nicht
> üppig damit bestückt ist.
Also wenn JSON schon deine Hardware in die Knie zwingt hast du ganz 
andere Probleme.

[Marco H. (damarco)]

Es sollte auf embedded Systeme lauffähig sein und diese nicht mit CPU 
Last oder Speicher in die Knie zwingen. In anbracht dieser Tatsache, 
lohnt es sich schon einmal darüber nachzudenken welche Ressourcen 
vorhanden sind.

Genauer gesagt könnte die Hardware eine Switch sein und die hat noch 
andere Dinge zu tun.

Das erzeugen von Json ist nicht das Problem, er das parsen. Es sei denn 
man macht das seriell... Nur hierzu gibt es wenig brauchbares... Alle 
Parser benötigen ein komplettes Object.

[Marco H. (damarco)]

Im Grunde geht es nicht darum mir hier eine Lösung vorzukauen.  Soweit 
wie ich das mitbekommen habe, macht jeder das so wie er es für richtig 
hält. Man passt eben das Framework an die API an. Alles ist erlaubt so 
lange es Dokumentiert ist...

Ich bin jetzt wieder etwas schlauer... Ich habe ein _warning und _error 
object angefügt.  So kann ich die values von den Geräten schon mal 
prüfen..

Es wäre schön wenn sich jemand findet der die Client Seite mit 
javascript und Angular etc. besser versteht. Um mir eben Tipps zu geben 
wie man das so gestaltet das es dafür brauchbar ist.