OPTIONS Methode für den Objektlink

[xdoo]

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]

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

[xdoo]

Die Fachlichkeit ist an dieser Stelle völlig irrelevant.

[dragonfly28]

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

[xdoo]

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

[rowe42]

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]

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 <#129 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AArgz1bjz_wKsaLC2jgzLBvpjwO41lIaks5tOf4xgaJpZM4Rt524> .

[dragonfly28]

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]

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]

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]

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:
mikekelly/hal_specification#24 (comment)
(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

• wir entweder admin_service auf eine höhere Spring-Version heben
• die OPTIONS-Requests doch irgendwie aktiviert werden

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]

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]

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:

• GET /animalsOptions
• GET /keepersOptions
• GET /enclosuresOptions

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

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

[rowe42]

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:

• In animad-form-behavior.html und animad-relation-behavior.html jeweils in Methode _loadOptions den HACK auskommentieren und die ursprüngliche Zeile (this._loadHalData(saveUrl, 'OPTIONS', 'data');) einkommentieren.
• Im Backend in animad_service in Klasse OptionsController.java die drei enthaltenen Methoden auf RequestMethod.OPTIONS umgestellt und den value auf "/<entity>" (also ohne ...Options)

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]

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