search

rowe42 / lhm_animad_admin_html5

0 stars 6 forks source link

OPTIONS Methode für den Objektlink #129

Closed xdoo closed 6 years ago

xdoo commented 6 years ago

Wenn man ein neues Objekt für eine Entität erstellen will, so hat man keine Kontextinformationen zur Verfügung. Diese bekommt man erst durch einen Request un der entsprechenden Payload. Aktuell gibt es dafür keinen Endpoint. Es wird deshalb im Backend für jeden

"[entity-name]s": {
        "href": "http://my-domain/[entity-name]s"
    }

ein 'OPTIONS' Endpunkt erstellt werden, der dann Informationen zu den Objektrelationen zurück liefert. Beispiel für folgenden Aufruf:

OPTIONS http://animad.mocklab.io/enclosures

gibt dann folgendes zurück:

{
  "_links": {
    "self": {
      "href": "http://animad.mocklab.io/enclosures"
    },
    "animals": {
        "href": "http://animad.mocklab.io/animals"
    },
    "keepers": {
        "href": "http://animad.mocklab.io/keepers"
    }
  }
}
dragonfly28 commented 6 years ago

Warum auch die keepers? "keepers": { "href": "http://animad.mocklab.io/keepers" } Die enclosures haben doch nur eine Relation zu den animals (animalList)?

xdoo commented 6 years ago

Die Fachlichkeit ist an dieser Stelle völlig irrelevant.

dragonfly28 commented 6 years ago

Sehe ich nicht so. Zur Referenzimplementierung gehört auch, dass nur die Relationen zur Auswahl angezeigt werden die modelliert und generiert wurden.

xdoo commented 6 years ago

Mag sein - ich sehe das anders. Das Issue ist neutral formuliert und mit einem fiktiven Beispiel veranschaulicht. Das bekommt @rowe42 schon hin.

rowe42 commented 6 years ago

Ich muss es aber erstmal verstehen. Und für mein Verständnis wäre schon interessant : in unserem konkreten Beispiel wäre keepers nicht drin, oder?

xdoo commented 6 years ago

Ja. Da kommen immer nur die Relationen des Objektes rein.

Am 26.01.2018 17:32 schrieb "rowe42" notifications@github.com:

Ich muss es aber erstmal verstehen. Und für mein Verständnis wäre schon interessant : in unserem konkreten Beispiel wäre keepers nicht drin, oder?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/xdoo/lhm_animad_admin_html5/issues/129#issuecomment-360834357, or mute the thread https://github.com/notifications/unsubscribe-auth/AArgz1bjz_wKsaLC2jgzLBvpjwO41lIaks5tOf4xgaJpZM4Rt524 .

dragonfly28 commented 6 years ago

Fiktive Beispiele wären besser an fiktiven Entitäten und Relationen erklärt. Das hier sorgt - wie zu sehen ist - nur für Verwirrung.

dragonfly28 commented 6 years ago

Ich stelle hier mal zur Diskussion, ob die OPTIONS-Methode überhaupt der richtige Weg ist, um Relationen abzufragen. Spring HATEOAS unterstützt per Default diese Methode und liefert dazu die möglichen (erlaubten) HTTP-Operationen für den angegebenen Link.

Beispiel: 

OPTIONS http://localhost:39146/animals```

liefert im Header folgende Info über die angefragte URL:

Access-Control-Allow-Methods →POST, PUT, PATCH, GET, OPTIONS, DELETE

... und keinerlei weiteren Content. Mit dieser Anpassung würden wir die grundlegende Semantik dieser Schnittstelle ändern und das Standardverhalten ändern. Ich konnte dazu kein Beispiel finden, gibt es hier Best Practices, dass man mit OPTIONS solche Informationen abrufen soll?

rowe42 commented 6 years ago

Ich muss zugeben mir kommt das auch seltsam vor. Normaler wäre, nach dem POST einen http 201 created sowie im body das gerade erstellte Objekt inklusive aller links zurück zu geben, oder? Etwas ähnliches steht auch in der spring doku: https://docs.spring.io/spring-data/rest/docs/current/reference/html/#repository-resources.default-status-codes

rowe42 commented 6 years ago

Also, grundsätzlich kann ich mir schon vorstellen, dass im OPTIONS Request neben den angebotenen HTTP-Verben im Body auch die angebotenen Links kommen. So etwas ähnliches wird auch hier vorgeschlagen: https://github.com/mikekelly/hal_specification/issues/24#issuecomment-71314321 (zweiter Post von Maks3w)

Allerdings bekomme ich es aktuell nicht hin: Der Admin_Service basiert derzeit auf Spring Cloud Brixton.SR7, das basiert auf Spring Boot 1.3.8 und ergibt spring-core-4.2.8. Standardmäßig sind in spring-core <4.3 OPTIONS-Requests deaktiviert. Man muss sie aktivieren, wie hier beschrieben: https://stackoverflow.com/questions/33331042/how-to-handle-http-options-requests-in-spring-boot Allerdings hat keine der Optionen 1-3 bei meinen Versuchen einen spürbaren Effekt gehabt (und Option 4 scheidet aus).

Eine andere Variante besteht darin, einfach auf Spring Core >=4.3 zu wechseln, da sind die OPTIONS standardmäßig aktiviert (habe ich in einem separaten Projekt ausprobiert). Nur habe ich stundenlang versucht, admin_service zu heben, aber bekomme diverse Probleme mit Hibernate und Lucene.

Ich habe in Branch _#129 mal etwas eingecheckt. Wenn man ein DELETE (anstatt eines OPTIONS) auf /enclosures macht, kommen die URLs wie oben gefordert. Wir müssen es also hinbekommen, dass

In dem Branch sind in Klasse MicroServiceApplication auch die Optionen 2 und 3 implementiert. Ihr könnt gerne anschauen, ob ich da was falsch gemacht habe.

rowe42 commented 6 years ago

Habe das jetzt mal vorerst in Branch _#156 (Pull Request #182) so per Workaround gelöst, dass ich statt OPTIONS hier mal GET aufrufe - da sind die benötigten Links auch drin und die (irrelevante) Payload im Showcase nicht so wahnsinnig groß...

rowe42 commented 6 years ago

Habe den Workaround nochmal umgebaut - das oben war nämlich der falsche GET-Request. Da ich noch immer darauf warte, dass das Backend nach dem Spring-Upgrade mit OPTIONS-Calls zurecht kommt, habe ich vorerst ins Backend drei neue Requests eingebaut:

Ist mitterweile im master. Auch die entsprechende Verarbeitung im Frontend.

Werde das umbauen, sobald es geht. So lange bleibt das Issue offen.

rowe42 commented 6 years ago

Ich kann das hier erst dann fixen, wenn das Backend auf die neue Spring-Version hochgezogen ist - also in der Version aus dem Generator.

D.h. erst in KW 13.

Was ich aber bereits ausprobiert habe:

Dann kann man zwar die Options unter OPTIONS http://localhost:8082/api/animad-administration-service/animals aufrufen. Das übersteuert aber leider das CrudRepository, so dass GET http://localhost:8082/api/animad-administration-service/animals nicht mehr funktioniert... :-(

rowe42 commented 6 years ago

Habe dies hier nun direkt im Barrakuda gefixt. Ist bereits von @a52team in den Branch polymer-ui2 übernommen worden. Schließe das Issue.