Ich bin auf der Suche nach einer Konvention zur Serialisierung meiner Daten, wenn ich eine (lange) Liste von Elementen habe, die ich an den Server senden möchte.
Wenn ich zum Beispiel eine Ressource /users habe und ich eine neue anhängen möchte, würde ich die Felder für den neuen Benutzer http-codieren und sie wie folgt in den Anfragetext einfügen: name=foo&age=20
Aber wenn ich eine Liste von Benutzern habe, wie diese [{ name: 'foo', age: 20 }, { name: 'bar', age: 10 }] , gibt es eine konventionelle Möglichkeit, dies zu POSTIEREN?
Ich denke name[0]=foo&age[0]=20&name[1]=bar&age[1]=10 , aber ich kann nichts finden, um es zu unterstützen. Was akzeptieren / erwarten Webserver normalerweise?
Schnelle Frage, die meine Antwort ändern kann: Senden Sie direkt von einem HTML-Formular POST oder erwarten Sie etwas raffinierteres (z. B. Javascript-Verarbeitung oder nicht einmal einen webbasierten Client)
Wenn Sie einen anspruchsvollen Client haben, können Sie einfach eine JSON-Zeichenfolge und einen POST mit dem Inhaltstyp application/json erstellen. Dann kann jede Ressource, die den POST verarbeitet, eine beliebige Anzahl von json-Bibliotheken verwenden, um die veröffentlichte Zeichenfolge zu lesen und so zu verarbeiten, wie sie ist.
Welchen Rahmen / welche Sprachen verwenden Sie, um Ihren REST-Service zu erstellen? Haben sie eingebaute Funktionalität / Konventionen, um Ihnen zu helfen?
Wenn Sie beispielsweise JAX-RS zum Erstellen Ihres Service verwenden, gibt es eine integrierte Annotation @ FormParam , die zur Verarbeitung von gebuchten Formularen verwendet werden können. Beispiel: Wenn Sie Folgendes mit dem Inhaltstyp application/x-www-form-urlencoded : name=foo&age=20&name=bar&age=10
Sie können parallele Listen auf der Serviceseite über:
abrufen %Vor%Aber Sie müssten sich dann mit der Frage beschäftigen, was ist, wenn eine Liste kürzer / länger ist als die andere, wie lösen Sie das auf? Was passiert, wenn ein neues Feld erforderlich oder optional ist, um eine Benutzerliste zu erstellen? (Aber wie ich eingangs erwähnt habe, würde ein JSON-Array von JSON-Objekten dieses Problem lösen ... es gibt eine Reihe von Bibliotheken, die automagische JSON-Deserialisierung in JAX-RS unterstützen, oder es gibt auch die Möglichkeit, eigene MessageBodyReader .
(Disclaimer zum nächsten Abschnitt: Ich kenne keine Rails, meine Erfahrung ist eher in der Java-Service-Welt ... Ich stütze das auf dieses Handbuch ). Es sieht so aus, als hätte Rails eine Konvention von name[]=foo&name[]=bar , um automatisch gepostete Daten in Arrays zu verarbeiten, und eine ähnliche Konvention, um Strukturen wie user[name]=foo&user[age]=20 zu füllen ... Wenn man auf Schienen ist, gibt es eine Möglichkeit beide zu benutzen / zu missbrauchen Funktionen, um das gewünschte Ergebnis zu erhalten?
Andere REST-Frameworks und -Sprachen können ihre eigenen Konventionen und Funktionen haben:)
Rails serialisiert Formulare in einem Format, das dem, was Sie vorschlagen, nicht unähnlich ist. Wenn Sie ein verschachteltes Modell haben, codiert es es so:
%Vor% (das äquivalente JSON wäre {"name": "theo", "company": {"name": "acme"}} )
Ich kann nicht sagen, dass ich eine Rails-Anwendung gesehen habe, die Arrays sendet, aber es gibt keinen Grund, warum es nicht funktionieren würde (im schlimmsten Fall würden Sie mit Hash-Schlüsseln einen Hash erhalten).
PHP hat eine andere Konvention, wenn Sie ein Array senden wollen, das Sie tun
%Vor%Aber ich weiß nicht, wie Sie verschachtelte Objekte so machen.
Die HTTP-Spezifikation oder, wenn es die URI-Spezifikation ist, nicht sicher, welche ATM, gibt tatsächlich an, dass wenn Sie dasselbe Argument mehrere Male übergeben, Sie Array von Werten erhalten (anstelle des Last-Wins-Verhaltens der meisten Anwendungsframeworks). Sie können dies in der API-Dokumentation für Jetty sehen, zum Beispiel: Ссылка )
Das meiste gilt jedoch für GET -Anfragen, nicht unbedingt POST (aber vielleicht sollte application/x-url-encoded denselben Standards entsprechen wie GET ).
Kurz gesagt, ich glaube nicht, dass es einen a Standard dafür gibt, POST bodies sind ein bisschen ein Gebiet im Wilden Westen. Ich denke jedoch, dass Sie entweder mit JSON gehen sollten, weil es Strukturen beschreibt, und application/x-url-encoded nicht, oder Sie sollten versuchen, die Struktur Ihrer Daten besser darzustellen, etwa wie folgt:
Das hat eine gewisse Chance, dass es zum Beispiel von einer Rails App out of the box interpretiert werden kann.