El nuevo método HTTP SEARCH

• Introducción al método SEARCH, añadido como un nuevo Draft en la IETF

• Para obtener datos complejos, usar solo GET/POST como hasta ahora resulta ineficiente

SEARCH /customers HTTP/1.1

Host: example.com

Content-Type: application/sql

SELECT username, email

WHERE DATEDIFF(DAY, GETDATE(), signup_date) > 7

• Esto no significa que sentencias SQL reales se vayan a usar como estándar, sino que este tipo de contenido para búsquedas puede ir en el request body

• Gracias a esto, para una misma URL ahora pueden coexistir GET, POST y SEARCH

• A través del header Accept-Search, se pueden especificar los formatos usados para la búsqueda :

→ Accept-Search: application/sql, application/graphql

• Basado en el estándar del método SEARCH que existía en WebDAV (rfc5323)

[beejei]

OData es una convención para hacer consultas de una forma casi muy similar. Pero que también se puedan usar application/sql y application/graphql en el mismo endpoint... la verdad, me cuesta imaginarlo.

[luavis]

Creo que se usaría en casos donde ejecutar SQL directamente es problemático y, como con Elasticsearch, semánticamente sería un GET, pero quieres hacer una consulta incluyendo un body HTTP.

[tmptmp]

En la parte inicial del texto dice "it was recently adopted as an IETF draft standard"; aquí, ¿ese "recently" se refiere a 2015? El draft que vi es este: https://tools.ietf.org/html/draft-snell-search-method-00, así que quería saber si hubo alguna actualización más reciente.

[xguru]

Es https://datatracker.ietf.org/doc/….

Parece que lo subieron recientemente, el 2021-03-31.

[tkwlsrl]

Si quieres enviar información en el body, tendrías que usar PUT o POST.

Como estos no pueden usar caché,

también se podría usar algo como SEARCH.

Después de todo, solo se enviaría en los casos en que se acepte.

[lallablah]

Me recuerda a GraphQL como una dirección para mejorar las incomodidades de get y post.

[superwoou]

Cuando uno empieza a pasar las consultas en el cuerpo de la solicitud, da la impresión de que en algún momento van a surgir problemas como SQL Injection (sobre todo si es un sitio hecho sin pensarlo mucho)..

[andrewchaa]

Creo que se puede entender más o menos como un GET con body. De todos modos, igual habría que validar el body...

[alstjr7375]

Así es..