J'ai du mal à comprendre, soap pass par http, qu'est ce qui t'empêche de compresser la requête et mettre le header content encoding qui va bien?
C’est effectivement comme ça que je l’avais implémenté à l’époque.
Et en quoi c'est pas standard?
Parce que ça ne l’est pas, à ma connaissance. Je veux bien que tu me trouves le standard, sinon. Mais les différents standards relatifs à HTTP que je connais ne parlent que de compression des réponses (et c’est relativement logique : le client ne peut pas à priori savoir si le serveur supporte la compression des requêtes).
Et dernièrement, en quoi json est épargné?
json n’est pas épargné. Mais un document json est généralement plus petit que le document xml équivalent, ce qui est exactement l’avantage que je soulignais. On m’a rétorqué que « de toute façon, on compresse donc c’est pas si grave » (ce qui se tient), sauf que dans les faits, c’est loin d’être toujours vrai.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: XML sapu et autres billevesées
Posté par whity . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
C’est effectivement comme ça que je l’avais implémenté à l’époque.
Parce que ça ne l’est pas, à ma connaissance. Je veux bien que tu me trouves le standard, sinon. Mais les différents standards relatifs à HTTP que je connais ne parlent que de compression des réponses (et c’est relativement logique : le client ne peut pas à priori savoir si le serveur supporte la compression des requêtes).
json n’est pas épargné. Mais un document json est généralement plus petit que le document xml équivalent, ce qui est exactement l’avantage que je soulignais. On m’a rétorqué que « de toute façon, on compresse donc c’est pas si grave » (ce qui se tient), sauf que dans les faits, c’est loin d’être toujours vrai.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0