Was ist zu tun, wenn eine GET-Anfrage nur dann sinnvoll ist, wenn der Anfrage spezifische Parameter zugeordnet sind? Sollten die Parameter als Abfragezeichenfolge übergeben werden, und wenn ja, was tun, wenn alle Parameter nicht angegeben oder falsch formatiert sind?
Nehmen wir beispielsweise an, ich habe eine Post-Ressource, auf die der Endpunkt "api / posts" zugreifen kann. Jeder Beitrag hat einen geografischen Standort und Beiträge können NUR abgerufen werden, wenn ein Bereich angegeben wird, in dem sich die Beiträge befinden können. Daher sind 3 Parameter erforderlich: Breite, Länge und Radius.
Ich kann mir in diesem Fall 2 Möglichkeiten vorstellen:
1. Setzen der Parameter in die Abfragezeichenfolge: api/posts/?lat=5.54158&lng=71.5486&radius=10
2. Setzen Sie die Parameter in die URL: api/posts/lat/5.54158/lng/71.5486/radius/10
Welche davon wäre der richtige Ansatz? Es scheint falsch zu sein, die erforderlichen Parameter in den Query-String zu schreiben, aber der letztere Ansatz fühlt sich etwas "hässlicher" an.
PS. Mir ist bewusst, dass es bereits viele Diskussionen zu diesem Thema gibt (zum Beispiel: REST API Best Practices: Wo sind Parameter zu platzieren? ), aber meine Frage ist speziell auf den Fall gerichtet, wenn Parameter benötigt werden, nicht optional.
Wenn Sie eine RESTful-API entwerfen, was tun, wenn eine GET-Anfrage nur ausgeführt wird Sinn, wenn der Anfrage spezifische Parameter zugeordnet sind? Sollten die Parameter als Abfragezeichenfolge übergeben werden, und wenn ja, was? wenn alle Parameter nicht angegeben oder formatiert sind falsch?
Bei REST muss Ihre API die REST-Einschränkungen erfüllen, die in der Fielding Dissertation
In Ihrem Fall spielt es keine Rolle, welche URI-Struktur Sie verwenden, es ist nur für die Service-Verwendung, da der Client immer die angegebene URI-Vorlage verwendet und es dem Client egal ist, was in dieser Vorlage ist, bis es eine gültige URI-Vorlage ist was es mit Parametern füllen kann.
In den meisten Fällen verfügt Ihr Client über ausreichende Validierungsinformationen, um zu testen, ob die Parameter falsch sind oder fehlen. In diesem Fall sendet es keine HTTP-Anfrage, Sie haben also nichts im Service zu tun. Wenn ein ungültiger Parameter durchkommt, sendet Ihr Dienst in Ihrem Fall eine 404 zurück - nicht gefunden, da der URI der Ressourcenbezeichner ist und keine Ressource zu einem ungültigen URI gehört (generiert aus der angegebenen URI-Vorlage und ungültigen Parametern) / p>
Der erste Ansatz ist besser.
%Vor%
Der zweite Ansatz ist ein wenig irreführend.
Sie sollten sich jedes Ihrer Verzeichnisse als Ressourcen vorstellen. In diesem Fall sind Unterressourcen (zum Beispiel: "api / posts / lat / 5.54158") nicht wirklich Ressourcen und somit irreführend. Es gibt Fälle, in denen dieses Muster eine bessere Lösung ist, aber wenn ich mir die gegebenen Informationen ansehe, würde ich die Abfragezeichenfolge verwenden. Es sei denn, du hast eine Entität, die dich verlinkt, um dich direkt mit dieser URL zu verlinken, mag ich nicht wirklich.
Sie sollten alles in die Abfragezeichenfolge eingeben und den Server so einstellen, dass er einen Fehlercode zurückgibt, wenn er die 3 erforderlichen Parameter nicht empfängt.
Weil es eine Gruppe von Parametern ist, die ein Objekt identifizieren.
Nehmen wir das Beispiel: lat = 5,54158; lng = 71.5486 radius = 10
Es wäre sehr unwahrscheinlich, dass diese URL einen Sinn ergibt:
api/posts/lat/5.54158/lng/yyyy/radius/zz
Es ist anders als:
api/memb/35/..
weil das Mitglied mit der ID 35 viele Funktionen (also gültige URLs) wie folgt haben kann:
api/memb/35/status oder
api/memb/35/lastlogin