RESTful-Ressourcen - akzeptiert eine Liste von Objekten

Baue ich eine Sammlung von Rest-Ressourcen, die Arbeit wie folgt: (ich nehme "Menschen" als ein Beispiel):

 GET /people/{key} 
- liefert ein person-Objekt (JSON) 

 GET /Menschen?first_name=Bob 
- gibt eine Liste von person-Objekten, die die "first_name" "Bob" (JSON) 

 PUT /people/{key} 
- erwartet wird ein person-Objekt in der Nutzlast (JSON), updates der Mensch in der 
datastore mit dem {key} gefunden in der URL-parameter entsprechend der Nutzlast. 
Wenn es ein neues Objekt, der Kunde gibt den Schlüssel des neuen Objekts.

Ich fühle mich sehr wohl mit dem design so weit (obwohl jeder input/Kritik ist willkommen).

Ich würde auch gerne in der Lage sein, eine Liste von Menschen, aber ich bin nicht zuversichtlich, in der RESTfulness mein design. Dies ist, was ich im Sinn haben:

 PUT /Menschen 
- erwartet eine Liste von Objekten in JSON-form mit Tasten in das Objekt aufgenommen 
("key":"32948"). Updates alle entsprechenden Objekte im datastore.

Dieser Vorgang wird idempotent, also würde ich gerne verwenden "SETZEN". Aber seine Regelverstöße, da eine GET-Anfrage an diese Ressource wird nicht wieder dem entspricht, was der Kunde gerade zu STELLEN, aber würde lieber wieder alle "Menschen" - Objekte (da gäbe es keine Filter auf die Abfrage). Ich vermute, es gibt auch noch ein paar andere Regeln, die könnte gebrochen werden, hier.

Jemand erwähnt die Verwendung von "PATCH" - Anfrage in einer früheren Frage, die ich hatte: REST-Ressource mit einer Eigenschaft List

"PATCH" klingt fantastisch, aber ich will nicht, es zu benutzen, denn es ist weder weit noch und ist nicht kompatibel mit vielen Programmen und APIs noch.

Würd ich lieber nicht POSTEN, weil die POST impliziert, dass die Anforderung ist nicht idempotent.

Hat jemand irgendwelche Kommentare /Anregungen?

Follow-up:::

Während ich zögerte, um die Verwendung buchen, denn es scheint der kleinste gemeinsame Nenner, catch-all für RESTful-Operationen und mehr kann gesagt werden über diesen Vorgang (speziell, dass es ist idempotent), DIE nicht eingesetzt werden, weil Ihre Forderungen sind zu schmal. Konkret: die Ressource ist nicht völlig neu geschrieben und die entsprechende Ressource wird nicht gesendet zurück von einer GET-Anforderung an dieselbe Ressource. Mit einer PUT mit Eigenschaften, die außerhalb der Spezifikationen liegen, können zu Problemen führen, wenn Anwendungen, api, und/oder Programmierer Versuch der Arbeit mit der Ressource, und sind erfüllt mit einem unerwarteten Verhalten der Ressource.

Zusätzlich zu den akzeptierten Antworten, Darrel Miller hatte einen ausgezeichneten Vorschlag, wenn der Betrieb musste unbedingt ein und das war zum Anhängen einer UUID auf das Ende der Ressourcen-Pfad, also ein äquivalent GET-Anforderung zurück, die äquivalente Ressource.

InformationsquelleAutor Chris Dutrow | 2010-07-07
  1. 8

    POST zeigt eine generische Aktionen als GET, PUT, und DELETE (die generische hashtable-Aktionen). Da die generische hashtable-Aktionen ungeeignet sind, verwenden Sie POST. Die Semantik von POST bestimmt werden, die von der Ressource, zu der eine Entität ist POSTed. Dies ist im Gegensatz zu der Semantik der generische hashtable-Methoden, die bekannt sind.

    POST /people/add-many HTTP/1.1
Host: example.com
Content-Type: application/json

[
  { "name": "Bob" },
  { "name": "Robert" }
]
    • Vielen Dank für Ihre Antwort. Habe ich verstanden, warum SETZEN Sie nicht technisch korrekt, aber das erklärt, warum ich sollte nicht brechen diese Regel.
    InformationsquelleAutor yfeldblum
  2. 3

    Unter Einsatz von PUT ist definitiv das falsche verb in diesem Fall. POST gemeint ist, genau das zu tun, was Sie Fragen. Aus der HTTP-Spezifikation:

    Den grundlegenden Unterschied zwischen POST und PUT Anfragen spiegelt sich in der unterschiedlichen Bedeutung der Anfrage-URI. Die URI in einer POST-Anforderung identifiziert die Ressource, die mit der eingeschlossenen Person. Diese Ressource könnte eine Daten-Annahme-Prozess, ein Tor zu einigen anderen Protokoll, oder eine separate Einheit, die akzeptiert Anmerkungen. Im Gegensatz dazu, der URI in eine PUT-Anforderung identifiziert die Entität, eingeschlossen mit den Wunsch-den user-agent weiß, was URI soll und der server MUSS NICHT versuchen auf anwenden, um die Anfrage zu einigen anderen Ressource...

    Als solche, wenn Sie möchten, aktualisieren Sie mehrere Ressourcen in einem einzigen Aufruf, Sie haben Verwendung POST.

    Einfach zu SETZEN, ist es erforderlich, idempotent und POST ist nicht, bedeutet nicht, dass POST nicht idempotent. Ihre Wahl der HTTP-verb sollte nicht sein, auf dieser Grundlage, sondern basiert auf der Beziehung der angeforderten Ressource, und die Ressource gehandelt. Wenn Ihre Anwendung direkt Umgang mit der Ressource angefordert, verwenden SETZEN. Wenn es handelt, die auf einigen anderen Ressourcen (oder Ressourcen, wie in Ihrem Fall), verwenden Sie den POST.

    InformationsquelleAutor AdmiralNemo
  3. 2

    Ich sehe wirklich nicht alle einfach Weg, Sie könnte verwenden, SETZEN Sie das erstellen einer beliebigen Gruppe von Menschen. Es sei denn, Sie sind bereit, um den client generiert eine GUID und etwas zu tun,

    PUT /PeopleList/{1E8157D6-3BDC-43b7-817D-C3DA285DD606}

    Auf der server-Seite, die Sie könnte nehmen Sie die Leute aus der Liste und fügen Sie Sie der /People Ressource.

    Eine leichte variation dieses Ansatzes wäre, um den server um einen link wie

    <link  href="/PeopleList/{1E8157D6-3BDC-43b7-817D-C3DA285DD606}"/>

    in der Menschen-Ressource. Die Kunden müssten wissen, dass es braucht, um eine Liste von Menschen, die AddList link. Der server benötigt, um sicherzustellen, dass jedes mal, es macht die /den Menschen Ressourcen-es wird eine neue url für die AddList link.

    • Das ist eine wirklich interessante Idee.
    InformationsquelleAutor Darrel Miller
  4. 0

    Bezüglich Darren Miller ' s Vorschlag mit einem GUID (ich kann nicht kommentieren...), der Punkt, der unter Einsatz von PUT-zu erzielen wäre idempotenz für den Betrieb. Der Lackmus-test, wenn idempotenz wäre dieses Gespräch zwischen dem client und dem server:

    1. PUT /PeopleList/{1E8157D6-3BDC-43b7-817D-C3DA285DD606}
    2. 204 NO CONTENT (zeigt an, dass es allen gut ging)
    3. client verliert die Verbindung und nicht sieht, dass die 204
    4. client automatisch Wiederholungen
    5. PUT /PeopleList/{1E8157D6-3BDC-43b7-817D-C3DA285DD606}

    Wie würden die server unterscheiden sich die beiden? Wenn die GUID ist "verbraucht", so zu sprechen, dann müssten die server reagieren 404 oder 410. Dies führt zu einem winzigen bisschen Konversation Status auf dem server zu erinnern, alle GUIDs, die benutzt wurden.

    Beiden Kunden würden oft die gleichen, die ich Schätze, weil der caching-oder einfach nur halten veraltete Antworten rund.

    Ich denke, eine intelligente Lösung ist die Verwendung von POST zu erstellen, der eine (zunächst leere, kurze Dauer) Wartebereich für eine Ressource, auf die man SETZEN kann, also Kunden, die POST müssen Sie zum erstellen der GUID-Ressource, anstatt zu entdecken, es über einen link:

    1. POST /PeopleList/CreateHoldingArea
    2. 201 CREATED und Location: /PeopleList/{1E8157D6-3BDC-43b7-817D-C3DA285DD606}
    3. PUT /PeopleList/{1E8157D6-3BDC-43b7-817D-C3DA285DD606}

    Dies würde bedeuten, dass die idempotenz verloren, würde nicht dazu führen, viel Aufwand, die Kunden einfach erstellen Sie neue GUIDs (durch Veröffentlichung), wenn Sie nicht sehen, die ersten 201 CREATED Antwort. Die "kleines bit des Klartext-Staat" würde jetzt nur die erstellt, aber noch nicht verwendet Griffbereichen.

    Die ideale Lösung wäre natürlich nicht notwendig, Klartext-Status auf dem server, aber es entzieht sich mir.

    InformationsquelleAutor mogsie
Schreibe einen Kommentar