Faraday: Elimina con cuerpos

Un PR estará disponible en breve para su revisión.

Hola @ Carlbc18 ,

¿Podría proporcionar un enlace a los cambios anteriores?
Supongo que eso solo es cierto para las especificaciones HTTP 2.0, por lo que es posible que debamos considerar esta característica con detenimiento.

https://tools.ietf.org/html/rfc7231#section -4.3.5

FYI: Este mismo bloque de texto se aplica también a las solicitudes GET && HEAD.

específicamente esta parte de la especificación:

Una carga útil dentro de un mensaje de solicitud DELETE no tiene semántica definida;
enviar un cuerpo de carga útil en una solicitud DELETE podría causar algunos
implementaciones para rechazar la solicitud.

Tengo un cambio de código con pruebas que funciona (no estoy seguro de si lo quieres). ¿Cómo creo un PR para este proyecto?

Supongo que eso solo es cierto para las especificaciones HTTP 2.0, por lo que es posible que debamos considerar esta característica con detenimiento.

esto es en realidad parte de HTTP 1.1

Definitivamente lo consideraría si desea crear un PR.
Puede hacerlo como con cualquier otro repositorio, simplemente bifurque faraday y aplique los cambios en su bifurcación, luego cree un PR en nuestra rama maestra.

Gracias @iMacTia. Lo pondré. ¿Cuál es su opinión sobre cambiar la versión finalmente tener un número de versión principal con esto? Este cambio podría ser rompedor para muchos. Me gustaría seguir el patrón semver y la versión faraday para ser 1.0.0 en este punto. Déjame saber lo que piensas.

Definitivamente estamos tratando de mantenernos en semver y hemos programado la v1.0 con algunos cambios importantes.
Si este cambio va a romper la compatibilidad con versiones anteriores, se lanzará solo en la versión 1.0 (que actualmente no tiene una fecha de lanzamiento fija).
Sin embargo, tengo entendido que ahora debería poder agregar OPCIONALMENTE un cuerpo a las solicitudes GET, HEAD y DELETE, así que ¿no debería ser compatible con versiones anteriores? ¿Me estoy perdiendo de algo?

@iMacTia i

Este es un seguimiento de mi https://github.com/lostisland/faraday/pull/695#issuecomment -305145499.
En primer lugar, debemos decidir CÓMO nos gustaría que funcione.
Suponiendo que los cambios deben ser compatibles con versiones anteriores, lo siguiente aún debería funcionar:

conn = Faraday.new(...)
conn.get('/path', {page: 1, per: 10})

# performs "GET /path?page=1&per=10"

La opción 1, como se indica en mi comentario, sería configurar este comportamiento:

conn = Faraday.new(..., standard: :http1_1)
conn.get('/path', {page: 1, per: 10})

# performs "GET /path" with body "page=1&per=10" (assuming www_form_url_encoded request)

La opción 2 en cambio significaría algo más poderoso:

conn = Faraday.new(...) # note no special config here
conn.get('/path', {page: 1, per: 10}, body: {some_key: 'some_value')

# performs "GET /path?page=1&per=10" with body "some_key=some_value"

Sin embargo, hay un problema, la opción 2 solo puede funcionar con ruby> = 2 ya que ruby ​​1.9 no admite parámetros de palabras clave 😞

Creo que con respecto a que esto no funciona en ruby ​​1.9, siento que está bien. Ruby 1.9 tiene muchos años. Yo recomendaría que la versión mejore a al menos 2.0 para la versión mínima de ruby, que iría en línea con una versión v1.0 de Faraday. También la opción 2 sigue más de cerca la especificación http 1.1 en mi opinión, ya que tendría la opción de pasar parms yo un cuerpo opcional.

Siento que intentar mantener la compatibilidad con versiones anteriores con una función de especificación http que funciona con ruby ​​1.9 va a causar problemas. Creo que esta característica sería más adecuada para V1 de Faraday. Siento que hay demasiadas variables que necesitan soporte para este cambio (ruby v, params pasando). Quizás estoy pensando demasiado ...

Creo que con respecto a que esto no funciona en ruby ​​1.9, siento que está bien. Ruby 1.9 tiene muchos años. Yo recomendaría que la versión mejore a al menos 2.0 para la versión mínima de ruby, que iría en línea con una versión v1.0 de Faraday. También la opción 2 sigue más de cerca la especificación http 1.1 en mi opinión, ya que tendría la opción de pasar parms yo un cuerpo opcional.

Estoy totalmente de acuerdo con todo lo anterior. De hecho, ese es el mejor curso de acción, aunque esto significa que todavía tendremos que esperar a la v1.0

Entonces, para definir una API compatible con versiones anteriores v1.0, podríamos intentar lo siguiente:

OBTENER, ENCABEZAR, ELIMINAR SOLICITUDES

conn = Faraday.new(...) # note no special config here
conn.get(path, url_params, body: {...})
# second parameter is URL PARAMS, optionally accept a named parameter for request body
# works the same for head and delete

PUBLICAR, PONER, SOLICITUDES DE PARCHE

conn = Faraday.new(...) # note no special config here
conn.post(path, body, url_params: {...})
# second parameter is REQUEST BODY, optionally accept a named parameter for url_params
# works the same for put and patch

¡Creo que de esta manera estamos cubriendo todas las combinaciones posibles y ampliando las solicitudes de publicación / colocación / parche también!

Definitivamente de acuerdo. ¿Queremos rechazar mi PR y abrir uno nuevo para esto? ¿Hay un corte de rama V1 con el que podamos trabajar?

Feliz de cerrar ese y comenzar desde cero, ya que será completamente diferente. ¡Lo siento por eso!

Crearé una rama V1 antes de fusionarme, así que siéntete libre de comenzar desde el maestro y redirigiré el PR :)

Hola @ Carlbc18, solo quería informarte que la sucursal 1.0 ya está disponible para ti 😃.

¡Gracias Gracias! 😀

Para cualquiera que todavía esté esperando esto, encontré la siguiente solución que parece funcionar en mi caso:

conn = Faraday.new
body = {
some_key: 'some value'
}
conn.run_request(:delete, url, body, headers)

Espero que esto ayude a alguien hasta que la eliminación ya no elimine el cuerpo de forma predeterminada

Entonces, ¿hay alguna actualización sobre cuándo estará disponible?

No he visto ningún PR todavía, pero los trabajos en v1 están progresando lentamente.
Es posible que pueda trabajar en esto yo mismo, pero no puedo dar una estimación en este momento.
La API actualizada sobre cómo deberían funcionar las solicitudes se explica en mi comentario anterior, por lo que si alguien quiere tener una oportunidad antes que yo, un PR es muy bienvenido.

Para una solución totalmente compatible con versiones anteriores, el PR se puede ramificar fuera del maestro y puedo hacer otra versión 0.x.
Si el cambio va a romper la compatibilidad con versiones anteriores, entonces es mejor ramificarse fuera de 1.0 branch

https://github.com/lostisland/faraday/pull/855 es un borrador de PR para respaldar esto.

Rechazo esta función. Puede utilizar el formulario de bloque en Faraday para realizar una solicitud con un cuerpo:

conn.delete(url) do |req|
  req.body = { some_key: 'some value' }
end

Esta idea habría hecho eliminaciones simples con cuerpos de una sola línea, pero la implementación agrega más complejidad y comportamiento sorprendente de lo que me gustaría. Esta forma de bloque ya funciona muy bien en Faraday. Prefiero modificar las propiedades de una clase a agregar más argumentos a un método:

conn.delete('/foo/1') do |req|
  req.headers["X-Men"] = "marvel"
  req.params[:confirm] = 1
  req.body = { some_key: 'some value' }
end