Aktionen in der REST API entwerfen - wann ist REST auch zu RESTful?

Ich bin in den Prozess der Entwicklung einer REST-API für ein Projekt an dem wir arbeiten. Das heißt, ich Schreibe die Spezifikationen später eingeführt werden.

Ich bin Sie haben Schwierigkeiten zu denken, in Substantive/Ressourcen statt Handlungen/Verben. Ohne in zu viel projektspezifika, wir schreiben eine API um SVN. Zum Beispiel, nehmen Sie die Aktion, die commits änderungen an den SVN-server. In unserem Projekt haben wir mehrere Definitionen/Versionen der commit-Aktion:

  • einfach verpflichten sich, alle geänderten Dateien
  • verpflichten, eine Liste der geänderten Dateien (eine Teilmenge, anstatt die ganze Reihe von geänderten Dateien)
  • ...

(1) Wie würden Sie die Gestaltung der URL? Die erste Frage ist, wie kann ich beschreiben die commit-Aktion als Substantiv/resource statt einer verb?

Manche würden sagen:

POST/PUT http://server.com/api/revision/commit

Sollte es ein POST oder eine PUT? Ich bin nicht wirklich die Schaffung eines commit-Ressourceso dass es keine POST. Allerdings bin ich mir nicht wirklich ändern commit-Ressourceso ist es nicht eine PUT. Eigentlich ist es nicht ein Ressourcees ist ein Aktion. Sobald die Aktion ausgeführt wird, ist es Weg, es gibt keine Ressource erstellt, geändert oder gehalten werden für eine spätere Referenz.

Das heißt, es muss eine Ressource, also die URL sollte wohl so sein

POST http://server.com/api/revision/commitment

Es ist auch ein POST, denn wir schaffen eine Verpflichtung. Sind wir nicht etwas ändern, also nicht SETZEN. Beachten Sie auch, dass ich geändert Begehen in Engagementder der Tatsache Rechnung tragen, dass wir im Umgang mit Ressourcen.

Macht das Sinn? Für mich ist es nicht, es treibt mich in den Wahnsinn. Ich möchte eine Aktion ausführen können, nicht schaffen, eine Ressource, die ähnelt der Aktion. Aber trotzdem.

Sagte, weiter zu gehen, ich gerade erstellt ein Engagement-Ressource. So logisch, ich sollte in der Lage sein, um es später auf:

GET http://server.com/api/revision/commitment/:id

Aber es gibt keine Verpflichtung Ressource! Ich war gezwungen, zu machen, um Erholsam. Kopf explodiert

Also, wie Sie richtig angeben-Aktionen auf die Ressourcen, die in einer REST-API? Ich spreche nicht über die Art der Maßnahmen, die eine Ressource erstellen (create user, ...), aber über die Art der Handlungen, die manipulieren, eine Ressource oder eine Handlung, die auf eine Ressource (commit revision, ...).

(2) Dann, zweitens, im Fall der zweiten definition (siehe oben), wie beschreiben wir die Teilmenge der geänderten Dateien? Über Parameter oder in eine Struktur (beispielsweise JSON-array) in den KÖRPER? Welche wird bevorzugt? Gibt es irgendwelche Allgemeinen Regeln?

Vielen Dank an alle!

InformationsquelleAutor der Frage Appelsien S. | 2011-07-15

  1. 14

    Manchmal ist es einfacher, wieder in eine URL-design als vorwärts gehen. Es scheint mir, wie das, was Sie fordern eine "Verpflichtung" ist eigentlich ein revision selbst. svn commit im Grunde bedeutet, "bitte akzeptieren Sie diese Unterschiede aus meiner aktuell ausgewählte revision als ein neues (Kinder -) revision". Daher müssen Sie feststellen, dass die aktuell ausgewählte revision (in der Reihenfolge zu bleiben stateless) und dann "anfügen", um es in einer sinnvollen Art und Weise:

    POST http://server.com/api/revisions/16/children/

    Ist, POST einer Person, die kapselt die Unterschiede von revision 16. Der server antwortet dann mit 201 Created plus Location: /api/revisions/23/ (oder /api/revisions/16/children/1die Umleitungen zu den ehemaligen).

    Dann, nicht nur haben Sie für die Schaffung von neuen Revisionen, aber auch wohl eine nützliche Liste der direkten Kinder einer revision.

    InformationsquelleAutor der Antwort fumanchu

  2. 2

    Aufhören zu denken in Maßnahmen ;D

    Zunächst legen Sie Ihre SVN werden Datei-basierte und basiert nicht auf einer Datenbank, die helfen, im denken.

    Wenn Sie denken, Sie haben nur 3 erholsamen (auch tatsächlich 4 vielleicht) - Operationen auf dem repository: svn add + svn commit, um eine neue Datei unter der version Kontrolle. Dieses übersetzt in einen PUT auf den Ordner, in dem Sie hinzufügen möchten, und übernehmen Sie die Datei. svnroot:/Projekt/Ordner in der Tat, wie die "id" der Datei bekannt ist, können Sie direkt auf die URL der Datei: svnroot:/Projekt/Ordner/Datei.c

    Möchten Sie eine änderung übergeben, das bedeutet ein POST auf die Ressource (nicht den Ordner, sondern die tatsächliche vorhandene Datei in diesem Ordner). POST svnroot:/Projekt/Ordner/Datei.c

    Wenn Sie möchten, um Dateien zu entfernen, es offensichtlich ist, zu LÖSCHEN.

    Wenn Sie wissen wollen, was Revisionsnummer eine bestimmte Datei verwenden Sie das STATUS.

    Gedanken in Bezug auf das, was tatsächlich geschieht, ist, nicht, wie die Verben genannt werden (co, ci, add, update usw.), was passiert, ist, dass Dateien 'erstellt' in das repository, das ist ein PUT, oder modifiziert, ist das ein POST oder gelöscht/entfernt das ist ein LÖSCHEN oder den status abgefragt wird, ist STATUS.

    Wenn Sie ermittelt werden, die Datei ist es natürlich eine BEKOMMEN.

    So, das oben ist eine aktuelle vorhandene Ressource. Jetzt könnten Sie beginnen zu erfinden, mehr Funktionen, geben Sie der Datei eine Größe und ein Autor oder letzten commiter oder eine commit-Nachricht! Nun müssen Sie die Arbeit auf die URLs, für die keine real-Ressource vorhanden ist. Manche nennen diese virtuellen Ressourcen.

    Fügen Sie einfach "/Autoren" etc. zum Ende der Ressource-URLs und verwenden Sie POST, fügen Sie ein Autor, und Lesen die Autoren. (Frage des Geschmacks, man kann auch verwenden SETZEN, wäre vielleicht mehr sauber nach dem REST-Paradigma)

    InformationsquelleAutor der Antwort Angel O'Sphere

Schreibe einen Kommentar