Hi,
seit ziemlich langer Zeit ist REST der letzte Schrei und RPC recht verpöhnt. Allerdings stelle ich mir die Frage, was das Problem wäre, beides zu mixen. Bsp.:
* Alle lesenden Requests REST-like
* Schreibende Requests RPC-like
In der Umsetzung wäre das dann etwa:
POST /users/register
PATCH /users/<id oder was auch immer> oder eben auch POST /users/<id oder was auch immer>/update oder so
GET /users/<id oder was auch immer>
...
Das sind keine finalen Endpunkte, sondern nur Ideen zur Verdeutlichung
Hat jemand so etwas schon mal umgesetzt? Der Vorteil wäre, dass man Daten- und Workflow-basierte Use-Cases sauberer abbilden kann.
Der eine oder andere denkt jetzt vermutlich "BUHH - Dann plane Deine API besser" oder "Never mix different things up". Beides valide Standpunkte. Aber ich denke, es lohnt sich, mal über den Tellerrand der eigenen Meinung zu schauen
seit ziemlich langer Zeit ist REST der letzte Schrei und RPC recht verpöhnt. Allerdings stelle ich mir die Frage, was das Problem wäre, beides zu mixen. Bsp.:
* Alle lesenden Requests REST-like
* Schreibende Requests RPC-like
In der Umsetzung wäre das dann etwa:
POST /users/register
PATCH /users/<id oder was auch immer> oder eben auch POST /users/<id oder was auch immer>/update oder so
GET /users/<id oder was auch immer>
...
Das sind keine finalen Endpunkte, sondern nur Ideen zur Verdeutlichung
Hat jemand so etwas schon mal umgesetzt? Der Vorteil wäre, dass man Daten- und Workflow-basierte Use-Cases sauberer abbilden kann.
Der eine oder andere denkt jetzt vermutlich "BUHH - Dann plane Deine API besser" oder "Never mix different things up". Beides valide Standpunkte. Aber ich denke, es lohnt sich, mal über den Tellerrand der eigenen Meinung zu schauen
Kommentar