Handhabung RESTful Repräsentationsstruktur Differenz zwischen POST und GET

Question

Ich bin eine REST-API Entwicklung und trotz einer Reihe von Praxisleitfäden Schleppen Ich kann nicht viel über die best practice der Handhabung der Disparität zwischen Repräsentationsstruktur finden benötigt für eine POST vs die gleiche Repräsentation Struktur von einer GET zurückgegeben.

GET für eine Dummy-user Darstellung könnte wie folgt aussehen:

{ 
    "id": 1234, 
    "created": "2012-04-23T18:25:43.511Z", 
    "username": "johndoe@example.com", 
    "name": "John Doe" 
} 

jedoch POST für die gleiche Dummy user Darstellung kann nicht angeben, bestimmte Eigenschaften (nämlich die id und created):

{ 
    "username": "johndoe@example.com", 
    "name": "John Doe" 
} 

Offensichtlich ist dies ein übermäßig vereinfachtes Beispiel, aber vorausgesetzt, dass der Benutzer bestimmte Felder nicht spezifizieren kann (und es möglicherweise nicht immer s ist offensichtlich, welche für die angewandte Methode relevant sind) ist es Best Practice separate Darstellungen für jede oder die vollständigste Version zu erstellen und die Daten Disparität transparent auf dem Server zu behandeln?

Trotz der scheinbaren Leichtigkeit, eine einzige Darstellung zu haben und die Disparitätsserverseite zu handhaben, mache ich mir Sorgen, dass dies für einen Benutzer eine schlechte Erfahrung wäre, wenn nicht klar wäre, welche Werte spezifiziert werden können (oder geändert werden können)). Wenn die Tendenz besteht, separate Repräsentationen zu erstellen, gibt es eine Namenskonvention für die Definition der Repräsentation?

z.B. i_user für eingehenden Benutzer und o_user für ausgehenden Benutzer. Oder user_full und user_min oder user und .user usw.

Update: Mein allzu vereinfachtes Beispiel vielleicht nicht richtig, das Problem veranschaulicht, hat. Stellen Sie sich eine Repräsentation mit 50 Eigenschaften vor (z. B. eine Serverdarstellung mit all ihren Überwachungsattributen - cpu, ram, temp, storage_drive_a, storage_drive_b, file_permission usw.). Von diesen 50 Eigenschaften sind 30 schreibgeschützte Eigenschaften und 20 davon sind Werte kann eingestellt werden.

Answer 1

Vor allem der letzte Semantik des POST Verfahrens wird durch die gezielte Ressource bestimmt, nicht durch das HTTP-Protokoll, wie bei den anderen Methoden, so dass Ihre POST Methode alles tun können Sie wollen, so lange wie Sie es dokumentieren richtig, und Sie replizieren keine Funktionalität, die bereits durch andere Methoden standardisiert ist.

Also kurz gesagt, es ist nichts falsch daran, eine andere Darstellung für POST und GET Methode. Die Frage nach einer Best-Practice in diesem Fall ist jedoch sinnlos, denn was das Darstellungsformat definiert, ist der verwendete Medientyp, nicht die Methode, aber die meisten der so genannten REST-APIs im Internet verwenden generische media-types für alles und Clients verlassen sich auf die URI-Semantik, um zu wissen, mit welcher Ressource sie es zu tun haben, die überhaupt nicht RESTful ist. Im Grunde fordern Sie die Best-Practice für ein Problem, das in REST nicht wirklich vorhanden ist, wenn die Dinge ordnungsgemäß ausgeführt werden.

So, um Ihre Frage zu beantworten, können Sie verschiedene Darstellungen mit verschiedenen Medien-Typen haben - wie Ihre komplette Benutzerrepräsentation könnte einen Medientyp application/vnd.mycompany.user.full.v1+json haben, und eine vereinfachte Benutzerdarstellung könnte einen Medientyp haben application/vnd.mycompany.user.min.v1+json - oder Sie können eine einzelne Darstellung wie application/vnd.mycompany.user.v1+json haben, und Ihre Dokumentation für diesen Medientyp könnte Details darüber enthalten, wie einige Eigenschaften existieren oder nicht, oder möglicherweise Standardwerte haben, wenn sie nicht bereitgestellt werden. Ihre POST-Methode erfordert, dass ein Medientyp funktioniert, und antwortet mit 415 Unsupported Media Type, wenn Clients etwas anderes im Header Content-Type senden. Auf dieselbe Weise kann ein Client die gewünschte Repräsentation mit dem Header Accept auswählen.

Wie Sie sehen, ist das, was Sie fragen, kein Problem, wenn Sie wirklich REST machen und es nicht nur als Schlagwort für eine HTTP-API verwenden.