tl;dr: o PSR-7 tem como objetivo modelar mensagens HTTP, enquanto o RFC pretende tornar algumas funcionalidades não orientadas a objetos do PHP mais próximas disso.
—————————————————————————————
Eu tinha pensado que a distinção entre a finalidade do PSR-7 e a finalidade do server-side request/response object RFC era óbvia a partir de suas descrições. Mas, aparentemente, este não é o caso.
Eu preferiria discutir o RFC inteiramente por seus próprios méritos e não me debruçar sobre os vários pontos fortes e fracos do PSR-7. No entanto, para reduzir a confusão sobre este tema, estou feliz por ter algum tempo para expor sobre as diferenças.
Para entender essas diferenças mais claramente, precisamos começar com uma história do PSR-7.
Objetivo do PSR-7
O PSR-7 nasceu para responder à pergunta: “Como podemos modelar mensagens HTTP em PHP para enviar uma solicitação e obter de volta uma resposta?” Ou seja, como podemos padronizar o modelo de uma mensagem de requisição HTTP para envio e o modelo resposta HTTP retornada, ao usar o PHP como um cliente HTTP?
O voto de acesso passou em janeiro de 2014, após cerca de um ano de pré-trabalho, com Michael “Guzzle” Dowling como líder. Veja o rascunho original.
O que você encontrará no rascunho é um par de interfaces de solicitação/resposta, descendente de uma interface de mensagem, com fluxo como corpo da mensagem e sem especificação de URI. Estes foram concebidos principalmente como interfaces de cliente; todos os projetos referenciados no rascunho eram do lado do cliente. (Como uma observação, eles eram mutáveis. Dowling disse: “Ter mensagens mutáveis e imutáveis acrescentaria uma quantidade significativa de complexidade a uma mensagem HTTP PSR e não refletiria o que está sendo usado atualmente por uma maioria de projetos PHP.”)
Após 8 meses, Dowling deixou o cargo, em agosto de 2014, alegando falta de tempo e motivação. Ele também disse: “Eu não acho que exista uma maneira de representar mensagens HTTP, clientes ou servidores em PHP”.
Pouco depois, em setembro de 2014, com o estímulo de muitos (incluindo o meu), MWOP do Zend Framework assume o PSR-7. Nós aprendemos que ele tem “Sencha Connect” e middleware no cérebro:
A razão pela qual eu queria dirigir Connect é esta: uma aplicação consiste em middleware. Cada middleware é um callback que aceita um pedido, uma resposta e um callback chamado “next” (que é opcional, na verdade):
function (request, response, next)…
Eu sei por Michael Dowling que a intenção original para o PSR-7 era definir mensagens HTTP que poderiam ser usadas em clientes HTTP. Estou aqui para argumentar que eles são ainda mais importantes quando se consideram aplicações do lado do servidor.
Neste ponto, vemos que o PSR-7 foi expandido para responder a uma segunda pergunta: “Como podemos modelar mensagens HTTP para receber uma solicitação e enviar de volta uma resposta?” Isso é além do objetivo original, mas a ideia é a mesmo: construir um modelo padrão de mensagens HTTP.
(Para divulgação completa, note que eu me tornei um patrocinador do PSR-7 em dezembro de 2014, juntamente com Beau Simensen como coordenador.)
É durante o mandato do MWOP, antes do sucesso da votação em maio de 2015, que as interfaces PSR-7 se expandem em número e se tornam “imutáveis” (com uma exceção intencional e outras exceções não intencionais).
Assim, podemos ver que o propósito do PSR-7 é modelar 2 conjuntos de mensagens HTTP usando 7 interfaces: um conjunto para quando o PHP envia um pedido e recebe uma resposta, e um conjunto de adição para quando o PHP recebe um pedido e envia uma resposta.
A finalidade do servidor (Request|Response) RFC
A RFC proposta começa por fazer uma pergunta diferente. Não se preocupa com a modelagem de mensagens HTTP, quer seja ao enviá-las ou recebê-las. Em vez disso, ela pergunta: “Como podemos levar os superglobais relacionados ao pedido em PHP e as várias funções globais relacionadas à resposta em PHP e encapsulá-los em objetos para torná-los, pelo menos, um pouco mais orientados a objetos?” Pelo fato de RFC começar com uma pergunta diferente, ela leva a uma resposta diferente.
Você acaba com um objeto ServerRequest que expõe quase somente as propriedades, imitando os superglobais do PHP. As propriedades são somente leitura, pois representam a entrada do usuário que deve ser copiada para fora, não alterada no local. Como uma conveniência, muitos valores comuns $ _SERVER [‘HTTP_ *’] são analisados em representações mais utilizáveis. Concedendo as necessidades de desenvolvimento de aplicativos, existem propriedades e métodos para valores verdadeiramente imutáveis relacionados a parâmetros específicos de aplicativo, entrada de conteúdo analisado e assim por diante.
Você também acaba com um objeto ServerResponse que expõe apenas métodos, imitando algumas das funções globais do PHP. Em vez de emitir cabeçalhos e cookies em cada chamada para os métodos relacionados, ele faz um buffer e retém os valores de cabeçalho e cookie até que você decida enviá-los. Como um ponto de coleta para esses valores e para o conteúdo, você pode inspecionar o estado do objeto antes do envio e modificá-lo conforme necessário. Ele tem alguns métodos de conveniência, incluindo o envio de conteúdo como um download, ou como JSON, com os cabeçalhos apropriados.
Conclusão
Espero que isso ajude a esclarecer qualquer confusão quanto à finalidade do RFC, versus a finalidade do PSR-7. Eles começam com perguntas diferentes e têm objetivos diferentes. Eu acho que seria melhor vê-los como ortogonais um ao outro na pior das hipóteses e complementares na melhor das hipóteses.
***
Paul M. Jones faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6498
Powered by WPeMatico