Faraday: Suppressions avec corps

Un PR sera bientôt disponible pour votre examen.

Salut @Carlbc18 ,

pourriez-vous s'il vous plaît fournir un lien vers les changements ci-dessus?
Je suppose que cela n'est vrai que pour les spécifications HTTP 2.0, nous devrons donc peut-être examiner attentivement cette fonctionnalité.

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

Pour info : ce même bloc de texte s'applique également aux requêtes GET && HEAD.

spécifiquement cette partie de la spécification:

Une charge utile dans un message de demande DELETE n'a pas de sémantique définie ;
l'envoi d'un corps de charge utile sur une demande DELETE peut entraîner des
implémentations pour rejeter la demande.

j'ai un changement de code avec des tests qui fonctionne (je ne sais pas si vous le voulez). comment puis-je créer un pr pour ce projet?

Je suppose que cela n'est vrai que pour les spécifications HTTP 2.0, nous devrons donc peut-être examiner attentivement cette fonctionnalité.

cela fait en fait partie de HTTP 1.1

Je l'envisagerais certainement si vous voulez créer un PR.
Vous pouvez le faire comme avec n'importe quel autre dépôt, il suffit de fork faraday et d'appliquer les modifications sur votre fork, puis de créer un PR à notre branche master.

Merci @iMacTia. Je vais le mettre. Quel est votre point de vue sur le changement de version a finalement un numéro de version majeur avec cela? Ce changement pourrait être brisé pour beaucoup. J'aimerais suivre le modèle semver et la version faraday doit être 1.0.0 à ce stade. Dites moi ce que vous en pensez.

Nous essayons définitivement de nous en tenir à semver et nous avons prévu la v1.0 avec quelques changements de rupture.
Si ce changement va rompre la compatibilité descendante, il ne sera publié que dans la version 1.0 (qui n'a actuellement pas de date de sortie fixe).
Cependant, si je comprends bien, vous devriez maintenant pouvoir ajouter FACULTATIVEMENT un corps aux requêtes GET, HEAD et DELETE, cela ne devrait-il donc pas être rétrocompatible ? Est-ce que j'ai raté quelque chose ?

@iMacTia i versionné à 0.13.0 et le PR est en place. Nous pouvons apporter toute autre conversation à ce sujet au PR car je suis sûr qu'il y aura des commentaires. Merci encore!

Ceci est un suivi sur mon https://github.com/lostisland/faraday/pull/695#issuecomment-305145499 .
Tout d'abord, nous devons décider COMMENT nous aimerions que cela fonctionne.
En supposant que les modifications doivent être rétrocompatibles, les éléments ci-dessous devraient toujours fonctionner :

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

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

L'option 1 comme indiqué dans mon commentaire serait de rendre ce comportement configurable :

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)

L'option 2 signifierait plutôt quelque chose de plus puissant :

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"

Il y a un problème cependant, l'option 2 peut ne fonctionner qu'avec ruby ​​>= 2 car ruby ​​1.9 ne prend pas en charge les paramètres de mot-clé 😞

Je pense que cela ne fonctionne pas sur ruby ​​1.9, je pense que ça va. Ruby 1.9 a plusieurs années. Je recommanderais que la version passe à au moins 2.0 pour la version ruby ​​minimale, ce qui irait en ligne avec une version v1.0 de Faraday. De plus, l'option 2 suit de plus près la spécification http 1.1 à mon avis, car vous auriez la possibilité de transmettre des paramètres et/ou un corps facultatif.

J'ai l'impression que tenter de maintenir la compatibilité descendante avec une fonctionnalité de spécification http qui fonctionne avec ruby ​​1.9 va poser des problèmes. Je pense que cette fonctionnalité serait mieux adaptée à la V1 de Faraday. J'ai l'impression qu'il y a trop de variables nécessaires pour prendre en charge ce changement (ruby v, passage des paramètres). Peut-être que je réfléchis trop....

Je pense que cela ne fonctionne pas sur ruby ​​1.9, je pense que ça va. Ruby 1.9 a plusieurs années. Je recommanderais que la version passe à au moins 2.0 pour la version ruby ​​minimale, ce qui irait en ligne avec une version v1.0 de Faraday. De plus, l'option 2 suit de plus près la spécification http 1.1 à mon avis, car vous auriez la possibilité de transmettre des paramètres et/ou un corps facultatif.

Je suis tout à fait d'accord avec tout ce qui précède. C'est en effet la meilleure chose à faire, même si cela signifie que nous devrons encore attendre la v1.0

Donc, pour définir une API rétrocompatible v1.0, nous pourrions essayer ce qui suit :

GET, HEAD, SUPPRIMER LES DEMANDES

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

POSTER, METTRE, PATCH DEMANDES

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

Je pense que de cette façon, nous couvrons toutes les combinaisons possibles et étendons également les requêtes post/put/patch !

Tout à fait d'accord. Voulons-nous refuser mon PR et en ouvrir un nouveau pour cela ? Y a-t-il une branche V1 coupée sur laquelle nous pouvons travailler?

Heureux de fermer celui-là et de recommencer à zéro car ce sera complètement différent. Désolé!

Je vais créer une branche V1 avant de fusionner, alors n'hésitez pas à commencer par master et je redirigerai le PR :)

Salut @Carlbc18 je voulais juste vous faire savoir que la branche 1.0 est maintenant disponible pour vous 😃.

Merci merci! ??

Pour ceux qui attendent toujours cela, j'ai trouvé la solution de contournement suivante qui semble fonctionner dans mon cas :

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

J'espère que cela aidera quelqu'un jusqu'à ce que la suppression ne supprime plus le corps par défaut

Alors, y a-t-il une mise à jour sur le moment où cela sera disponible?

Je n'ai pas encore vu de relations publiques, mais les travaux sur la v1 progressent lentement.
Je pourrais peut-être y travailler moi-même mais je ne peux pas donner d'estimation pour le moment.
L'API mise à jour sur le fonctionnement des demandes est expliquée dans mon commentaire ci-dessus, donc si quelqu'un veut essayer avant moi, un PR est le bienvenu.

Pour une solution entièrement rétrocompatible, le PR peut être dérivé du maître et je peux créer une autre version 0.x.
Si le changement va rompre la compatibilité descendante, il est préférable de sortir de la branche 1.0

https://github.com/lostisland/faraday/pull/855 est un projet de relations publiques pour soutenir cela.

Je rejette cette fonctionnalité. Vous pouvez utiliser le formulaire de blocage dans Faraday pour faire une demande avec un corps :

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

Cette idée aurait fait de simples suppressions avec des corps une seule doublure, mais la mise en œuvre ajoute plus de complexité et de comportement surprenant que je ne le souhaiterais. Cette forme de bloc fonctionne déjà très bien à Faraday. Je préfère modifier les propriétés d'une classe plutôt que d'ajouter plus d'arguments à une méthode :

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