Faraday: Exclui com corpos

Um PR estará disponível em breve para sua revisão.

Olá @ Carlbc18 ,

você poderia fornecer um link para as alterações acima?
Eu acho que isso só é verdade para especificações HTTP 2.0, portanto, talvez seja necessário considerar esse recurso com cuidado.

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

Para sua informação: este mesmo bloco de texto se aplica a solicitações GET && HEAD também.

especificamente esta parte da especificação:

Uma carga dentro de uma mensagem de solicitação DELETE não tem semântica definida;
enviar um corpo de carga útil em uma solicitação DELETE pode causar alguns
implementações para rejeitar o pedido.

Eu tenho uma alteração de código com testes que funciona (não tenho certeza se você quer). como faço para criar um pr para este projeto?

Eu acho que isso só é verdade para especificações HTTP 2.0, portanto, talvez seja necessário considerar esse recurso com cuidado.

na verdade, isso faz parte do HTTP 1.1

Eu definitivamente consideraria se você quiser criar um PR.
Você pode fazer isso como com qualquer outro repo, simplesmente fork faraday e aplique as alterações em seu fork, então crie um PR para nosso branch master.

Obrigado @iMacTia. Eu vou colocá-lo. Qual é a sua opinião sobre como mudar a versão, finalmente, ter um número de versão principal com isso? Essa mudança pode ser prejudicial para muitos. Eu gostaria de seguir o padrão semver e a versão faraday como 1.0.0 neste ponto. Deixe-me saber a sua opinião.

Definitivamente, estamos tentando manter o semver e temos a v1.0 programada com algumas mudanças importantes.
Se essa mudança vai quebrar a compatibilidade com versões anteriores, então ela será lançada apenas na versão 1.0 (que atualmente não tem uma data de lançamento fixa).
No entanto, meu entendimento é que agora você deve ser capaz de OPCIONALMENTE adicionar um corpo às solicitações GET, HEAD e DELETE, então isso não deveria ser compatível com versões anteriores? Estou esquecendo de algo?

@iMacTia i versionado para 0.13.0 e o PR está ativo. Podemos levar qualquer outra conversa sobre isso para o PR, pois tenho certeza de que haverá comentários. Obrigado novamente!

Este é um acompanhamento do meu https://github.com/lostisland/faraday/pull/695#issuecomment -305145499.
Em primeiro lugar, devemos decidir COMO gostaríamos que isso funcionasse.
Assumindo que as alterações devem ser compatíveis com versões anteriores, o seguinte ainda deve funcionar:

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

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

A opção 1, conforme declarado em meu comentário, seria tornar esse comportamento configurável:

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)

Em vez disso, a opção 2 significaria algo mais 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"

Porém, há um problema, a opção 2 pode funcionar apenas com ruby> = 2, pois ruby ​​1.9 não suporta parâmetros de palavra-chave 😞

Eu acho que com relação a isso não funcionar no Ruby 1.9, eu sinto que está tudo bem. Ruby 1.9 tem muitos anos. Eu recomendaria que a versão aumentasse para pelo menos 2.0 para a versão ruby ​​mínima, que iria em linha com uma versão v1.0 do Faraday. Além disso, a opção 2 segue mais de perto as especificações http 1.1 na minha opinião, pois você teria a opção de passar parâmetros e / ou um corpo opcional.

Eu sinto que tentar manter a compatibilidade com versões anteriores com um recurso de especificação de http que funciona com ruby ​​1.9 vai causar problemas. Acho que esse recurso seria mais adequado para V1 de Faraday. Eu sinto que há muitas variáveis ​​precisando de suporte para essa mudança (ruby v, passagem de parâmetros). Talvez eu esteja pensando demais ...

Eu acho que com relação a isso não funcionar no Ruby 1.9, eu sinto que está tudo bem. Ruby 1.9 tem muitos anos. Eu recomendaria que a versão aumentasse para pelo menos 2.0 para a versão ruby ​​mínima, que iria em linha com uma versão v1.0 do Faraday. Além disso, a opção 2 segue mais de perto as especificações http 1.1 na minha opinião, pois você teria a opção de passar parâmetros e / ou um corpo opcional.

Eu concordo totalmente com tudo o que foi dito acima. Esse é realmente o melhor curso de ação, embora isso signifique que ainda teremos que esperar pela v1.0

Portanto, para definir uma API compatível com versões anteriores v1.0, podemos tentar o seguinte:

GET, HEAD, DELETE REQUESTS

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, PUT, PATCH REQUESTS

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

Acho que dessa forma estamos cobrindo todas as combinações possíveis e estendendo as solicitações de post / put / patch também!

Definitivamente concordo. Queremos recusar meu PR e abrir um novo para isso? Existe um corte de ramal V1 que podemos trabalhar fora?

Fico feliz em fechar esse e começar do zero, pois será completamente diferente. Desculpe por isso!

Vou criar um branch V1 antes de mesclar, fique à vontade para começar a partir do master e redirecionarei o PR :)

Olá @ Carlbc18, só queria que você soubesse que o branch 1.0 já está disponível para você 😃.

Obrigada, obrigada! 😀

Para quem ainda está esperando por isso, encontrei a seguinte solução alternativa que parece funcionar no meu caso:

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

Espero que isso ajude alguém até que a exclusão não anule mais o corpo por padrão

Então, há alguma atualização sobre quando isso estará disponível?

Eu não vi nenhum PR ainda, mas os trabalhos na v1 estão progredindo lentamente.
Eu posso trabalhar nisso sozinho, mas não posso dar uma estimativa no momento.
A API atualizada sobre como as solicitações devem funcionar é explicada no meu comentário acima, então, se alguém quiser tentar isso antes de mim, um PR é muito bem-vindo.

Para uma solução totalmente compatível com versões anteriores, o PR pode ser ramificado do mestre e posso fazer outra versão 0.x.
Se a mudança vai quebrar a compatibilidade com versões anteriores, então é melhor ramificar fora de 1.0 branch

https://github.com/lostisland/faraday/pull/855 é um rascunho de PR para apoiar isso.

Estou rejeitando esse recurso. Você pode usar o formulário de bloqueio em Faraday para fazer uma solicitação com um corpo:

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

Essa ideia teria feito exclusões simples com corpos de um único liner, mas a implementação adiciona mais complexidade e comportamento surpreendente do que eu gostaria. Este formulário de bloco já funciona muito bem em Faraday. Eu prefiro modificar propriedades em uma classe a adicionar mais argumentos a um método:

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