Die neue HTTP-Methode SEARCH
(httptoolkit.tech)-
Vorstellung der SEARCH-Methode, die als neuer Draft zur IETF hinzugefügt wurde
-
Um komplexe Daten abzurufen, sind die bisherigen GET/POST-Methoden allein ineffizient
SEARCH /customers HTTP/1.1
Host: example.com
Content-Type: application/sql
SELECT username, email
WHERE DATEDIFF(DAY, GETDATE(), signup_date) > 7
-
Tatsächlich wird eine SQL-Anweisung nicht als Standard verwendet; gemeint ist, dass solche Inhalte für Suchanfragen im Request-Body möglich sind
-
Dadurch werden für eine einzelne URL GET, POST und SEARCH zugleich möglich
-
Über den Accept-Search-Header lassen sich die für die Suche verwendeten Formate festlegen:
→ Accept-Search: application/sql, application/graphql
- Basiert auf dem SEARCH-Methodenstandard aus WebDAV (rfc5323)
9 Kommentare
OData ist ein Standard, der Abfragen auf fast ähnliche Weise ermöglicht. Dass man aber
application/sqlundapplication/graphqlam selben Endpoint verwenden kann … das kann ich mir nur schwer vorstellen.Ich denke, der Einsatzzweck selbst wäre, dass es problematisch ist, direkt SQL abzusetzen, und man es in Fällen verwenden könnte, in denen es semantisch wie ein GET ist, man aber wie bei Elasticsearch mit einem HTTP-Body eine Abfrage durchführen möchte.
Im einleitenden Teil steht „it was recently adopted as an IETF draft standard“ – ist das hier mit „recently“ tatsächlich 2015 gemeint? Der Draft, den ich gefunden habe, ist https://tools.ietf.org/html/draft-snell-search-method-00. Gibt es dazu vielleicht neuere Änderungen?
Es ist https://datatracker.ietf.org/doc/….
Offenbar wurde es zuletzt am 2021-03-31 hochgeladen.
Wenn man Informationen im Body mitsenden will, müsste man wohl PUT oder POST verwenden.
Diese können aber keinen Cache nutzen,
da könnte man also auch so etwas wie SEARCH verwenden.
Schließlich würde man es ja nur senden, wenn es akzeptiert wird.
Da denke ich an GraphQL als einen Ansatz, der die Unbequemlichkeiten von GET und POST verbessern soll.
Sobald man anfängt, Abfragen im Request-Body zu übergeben, hat man irgendwie das Gefühl, dass irgendwann Probleme wie SQL Injection auftauchen werden (vor allem, wenn die Website ohne großes Nachdenken gebaut wurde)..
Man kann es wohl ungefähr als GET mit Body verstehen. Den Body muss man ohnehin validieren …
Stimmt schon..