Vídeo: Coisas que todo programador deveria saber - Web Services 2024
Os Serviços da Web da Amazon (AWS) inicialmente lançados com suporte SOAP para interações com sua API, mas tem obsoleto (reduziu seu suporte Por outras palavras, a sua interface SOAP em favor do REST. A melhor recomendação para qualquer uso da AWS API é que você se concentra no uso de REST.
Dessa forma, você não vai acabar com programas que algum dia deixam de funcionar - muito depois de esquecer os detalhes dos mecanismos de interação. A experiência da tarefa desagradável de ter que voltar a um sistema e tentar reconstruir suas ações de meses ou anos antes é uma desafortunada.
Não há sentido no destino tentador da AWS - se você quiser interagir com a AWS API, use o REST, que é a direção de longo prazo da Amazon.
A abordagem mais antiga, o SOAP (abreviação de Simple Object Access Protocol), teve um suporte generalizado da indústria, com um conjunto abrangente de padrões. Esses padrões eram muito abrangentes, infelizmente. As pessoas que criam o SOAP configuraram-se para ser extremamente flexível - pode se comunicar através da web, e-mail e redes privadas. Para garantir a segurança e a capacidade de gerenciamento, também foram definidas várias normas de suporte que se integram ao SOAP.
O SOAP é baseado em um padrão de codificação de documento conhecido como Extensible Markup Language (XML, para abreviar) e o serviço SOAP é definido de tal forma que os usuários podem alavancar XML, não importa O que é a rede de comunicação subjacente. Para que este sistema funcione, no entanto, os dados transferidos pelo SOAP (comumente chamado de carga útil ) também precisam estar no formato XML.
Observe um padrão aqui? O empurrão para ser abrangente e flexível (ou, para ser tudo para todas as pessoas), além do requisito de carga útil XML, significa que o SOAP acabou sendo bastante complexo, tornando muito trabalho a usar corretamente. Como você pode imaginar, muitas pessoas de TI encontraram o SOAP desanimador e, consequentemente, resistiram ao uso dele.
Cerca de uma década atrás, um aluno de doutorado definiu outra abordagem de serviços web como parte de sua tese: REST, ou Representational State Transfer. REST, que é muito menos abrangente do que o SOAP, aspira a resolver menos problemas. Não aborda alguns aspectos do SOAP que pareciam importantes, mas que, em retrospectiva, tornaram mais complexo o uso - segurança, por exemplo.
O aspecto mais importante do REST é que ele foi projetado para se integrar com protocolos web padrão para que os serviços REST possam ser chamados de verbos e URLs padrão da Web. Por exemplo, uma chamada REST válida parece assim:
// search.examplecompany. com / CompanyDirectory / EmployeeInfo? empname = BernardGolden
Isso é tudo o que é preciso para fazer uma consulta ao serviço REST de examplecompany para ver informações de pessoal. O verbo HTTP que acompanha esse pedido é GET, pedindo que as informações sejam retornadas. Para excluir informações, você usa o verbo DELETE. Para inserir informações, você usa o verbo POST. Para atualizar informações, você usa o verbo PUT.
Para as ações POST e PUT, informações adicionais acompanham o empname e serão separadas por um e comercial (&) para indicar outro argumento a ser usado pelo serviço.
REST não impõe requisitos de formatação específicos nas cargas úteis do serviço; a este respeito, difere do SOAP, que requer XML. Para interações simples, uma série de bytes é tudo que você precisa para a carga útil; Para interações mais complexas (por exemplo, além de retornar a informação do seu funcionário, você deseja fazer uma solicitação para a informação do funcionário de todos os funcionários cujos nomes começam com G), a convenção de codificação JSON é usada. (JSON, se você for curioso, significa a Notificação de Objeto do Javascript).
Como você poderia esperar, o modelo de uso mais simples da REST, seu alinhamento com protocolos e verbos padrão da Web e sua formatação de carga útil menos restritiva tornaram-se atraentes com desenvolvedores Como uma casa em chamas.
