Ich schreibe eine RESTful HATEOAS API. Ich habe zusammengesetzte Entitäten, die ich GET, POST und PUT habe. Der GET-Teil ist einfach und hat viele Beispiele. Die Antwort enthält die primitiven Attribute der Entität und Verknüpfungen zu verschachtelten Entitäten. Zum Beispiel:
%Vor% Das Problem tritt auf, wenn ich das Konto erstellen oder ändern möchte. Ich muss das Konto mit einem accountType verknüpfen. Ich kann eine POST-Anfrage wie folgt senden: {"firstName":"Michael","lastName":"Jackson","balance":300.0,"accountTypeId":5}
aber das würde das HATEOAS-Paradigma brechen. Was ist die beste Vorgehensweise, um zusammengesetzte Entitäten POST / PUT zu setzen?
Es gibt nichts besonderes an dieser Nutzlast, die gegen HATEOAS gehen würde; Das einzige wirkliche Problem ist, dass das accountTypeId nicht sehr auffindbar ist. (Magische IDs werden immer besser in kurze beschreibende Strings umgewandelt. Stellen Sie sich vor, dass sie wie eine Aufzählung sind.) Eines der wichtigsten Dinge, die Sie bei der Arbeit mit einem HATEOAS-Modell beachten sollten, ist die Entität, die der Benutzer POSTs nicht benötigt genau die Entität, die die Ressource erstellt; Sie können es ändern, kommentieren, übersetzen. Es sollte immer noch konzeptionell gleich sein, aber das ist völlig anders als identisch . (Das Hinzufügen von IDs und Erstellungszeitstempeln wäre ein hervorragendes Beispiel dafür, wie eine Erweiterung sinnvoll wäre.)
Für mich klingt es so, als ob Ihr wirkliches Problem ist, dass Sie genau überlegen müssen, welche Informationen Clients bei einem POST einreichen sollen und wie Sie Kunden sagen, dass sie diese Informationen einreichen sollten die Post. Ich mag es durchaus, XML hier zum Hochladen zu verwenden, da ich Clients leicht sagen kann, dass ihre POST-Nutzdaten einem bestimmten Schema entsprechen sollten (und sowohl XML-Schema als auch RELAX NG sind reich genug, um die Einschränkungen zu beschreiben). Ich bin mir sicher, dass das nicht der einzige Weg ist.