Qual é a diferença entre HTTP e REST?

Depois de ler muito sobre as diferenças entre REST e SOAP, tive a impressão de que REST é apenas mais uma palavra para HTTP. Alguém pode explicar que funcionalidade o REST adiciona ao HTTP?

Nota : Não estou procurando uma comparação entre REST e SOAP.

Atualização : Obrigado por suas respostas. Agora ficou claro para mim que o REST é apenas um conjunto de regras sobre como usar o HTTP. Por isso, postei um acompanhamento sobre quais são as vantagens dessas convenções .

Nota : Agora compreendo o significado de REST; Como observa Emil Ivanov , REST significa usar HTTP do jeito que deveria ser. No entanto, não tenho certeza se isso merece um termo próprio e certamente não entendo o que é isso.

Não, REST é a maneira como o HTTP deve ser usado .

Hoje usamos apenas um pouquinho dos métodos do protocolo HTTP - ou seja, GETe POST. A maneira REST de fazer isso é usar todos os métodos do protocolo.

Por exemplo, o REST determina o uso de DELETEapagar um documento (seja um arquivo, estado, etc.) atrás de um URI, enquanto que, com o HTTP, você usurparia uma consulta GETou POSTcomo ela ...product/?delete_id=22.

HTTP é um protocolo usado para comunicação, geralmente usado para se comunicar com recursos da Internet ou qualquer aplicativo com um cliente de navegador da Web.

REST significa que o principal conceito que você está usando ao projetar o aplicativo é o Recurso: para cada ação que você deseja executar, é necessário definir um recurso no qual você geralmente realiza apenas operações CRUD, o que é uma tarefa simples. por isso, é muito conveniente usar 4 verbos usados ​​no protocolo HTTP contra as 4 operações CRUD (Get for Read, POST é para CREATE, PUT é para UPDATE e DELETE é para DELETE). isso é diferente do conceito mais antigo de RPC (Remote Procedure Call), no qual você tem um conjunto de ações que deseja executar como resultado da chamada do usuário. se você pensa, por exemplo, em como descrever um facebook como em uma postagem, com o RPC, você pode criar serviços chamados AddLikeToPost e RemoveLikeFromPost e gerenciá-lo juntamente com todos os outros serviços relacionados a postagens do FB, portanto, não será necessário criar recursos especiais. objeto para Like. com o REST, você terá um objeto Like, que será gerenciado separadamente com as funções Delete e Create. Isso também significa que descreverá uma entidade separada em seu banco de dados. isso pode parecer uma pequena diferença, mas trabalhar dessa maneira geralmente produziria um código muito mais simples e um aplicativo muito mais simples. com esse design, a maior parte da lógica do aplicativo é óbvia a partir da estrutura (modelo) do objeto, ao contrário da RPC com a qual você normalmente teria que adicionar explicitamente muito mais lógica.

projetar aplicativos RESTful geralmente é muito mais difícil, pois exige que você descreva coisas complicadas de uma maneira simples. descrever todas as funcionalidades usando apenas funções CRUD é complicado, mas depois disso, sua vida será muito mais simples e você descobrirá que escreverá métodos muito mais curtos.

Mais uma arquitetura REST de restrição presente é não usar o contexto da sessão ao se comunicar com o cliente (sem estado), significando que todas as informações precisam entender quem é o cliente e o que ele deseja é passado com a mensagem da web. cada chamada para uma função é auto-descritiva, não há conversa anterior com o cliente que possa ser referenciada na mensagem. portanto, um cliente não pode dizer "me dê a próxima página", pois você não tem uma sessão para armazenar qual é a página anterior e que tipo de página você deseja, o cliente teria que dizer "meu nome é yuval, obtenha me página 2 de uma postagem específica em um fórum específico ". isso significa que um pouco mais de dados precisariam ser transferidos na comunicação, mas pense na diferença entre encontrar um bug relatado a partir da função "obtenha-me na próxima página" em oposição a "

É claro que há muito mais, mas, na minha opinião, esses são os principais conceitos de uma colher de chá.

HTTP é um protocolo de aplicação. REST é um conjunto de regras que, quando seguidas, permitem criar um aplicativo distribuído que possui um conjunto específico de restrições desejáveis.

Se você estiver procurando pelas restrições mais significativas do REST que distinguem um aplicativo RESTful de qualquer aplicativo HTTP, eu diria que a restrição de "auto-descrição" e a restrição hipermídia (também conhecida como hipermídia como o estado do mecanismo de aplicativo (HATEOAS)) são o mais importante.

A restrição de auto-descrição requer que uma solicitação RESTful seja completamente auto-descritiva na intenção do usuário. Isso permite que intermediários (proxies e caches) atuem com segurança na mensagem.

A restrição HATEOAS consiste em transformar seu aplicativo em uma rede de links em que o estado atual do cliente se baseia em seu lugar nessa web. É um conceito complicado e requer mais tempo para explicar do que tenho agora.

Pelo que entendi, o REST impõe o uso dos comandos HTTP disponíveis como eles deveriam ser usados.

Por exemplo, eu poderia fazer:

GET
http://example.com?method=delete&item=xxx

Mas, com o resto, eu usaria o método de solicitação "DELETE", removendo a necessidade do parâmetro de consulta "method"

DELETE
http://example.com?item=xxx

Não é bem assim ...

http://en.wikipedia.org/wiki/Representational_State_Transfer

O REST foi descrito inicialmente no contexto do HTTP, mas não está limitado a esse protocolo. As arquiteturas RESTful podem basear-se em outros protocolos da Camada de Aplicativos se eles já fornecerem um vocabulário rico e uniforme para aplicativos com base na transferência de um estado representacional significativo. Os aplicativos RESTful maximizam o uso da interface pré-existente e bem definida e outros recursos internos fornecidos pelo protocolo de rede escolhido e minimizam a adição de novos recursos específicos do aplicativo.

http://www.looselycoupled.com/glossary/SOAP

(Simple Object Access Protocol) O padrão para mensagens de serviços da web. Com base no XML, o SOAP define um formato de envelope e várias regras para descrever seu conteúdo. Visto (com WSDL e UDDI) como um dos três padrões básicos de serviços da web, é o protocolo preferido para a troca de serviços da web, mas de maneira alguma o único; Os defensores do REST dizem que ele adiciona complexidade desnecessária.

O REST é uma maneira específica de abordar o design de grandes sistemas (como a web).

É um conjunto de 'regras' (ou 'restrições').

HTTP é um protocolo que tenta obedecer a essas regras.

REST = Transferência Representacional do Estado

DESCANSAR é um conjunto de regras que, quando seguidas, permitem criar um aplicativo distribuído que possui um conjunto específico de restrições desejáveis.

O REST é um protocolo para trocar mensagens (XML, JSON etc.) que podem usar HTTP para transportar essas mensagens.

Recursos:

É sem estado, o que significa que, idealmente, nenhuma conexão deve ser mantida entre o cliente e o servidor. É de responsabilidade do cliente transmitir seu contexto para o servidor e, em seguida, o servidor pode armazenar esse contexto para processar a solicitação adicional do cliente. Por exemplo, a sessão mantida pelo servidor é identificada pelo identificador de sessão passado pelo cliente.

Vantagens da apatridia:

1. Os Serviços da Web podem tratar cada chamada de método separadamente.
2. Os Serviços da Web não precisam manter a interação anterior do cliente.
3. Por sua vez, isso simplifica o design do aplicativo.
4. O próprio HTTP é um protocolo sem estado diferente do TCP e, portanto, o RESTful Web Services funciona perfeitamente com os protocolos HTTP.

Desvantagens da apatridia:

1. Uma camada extra na forma de cabeçalho precisa ser adicionada a cada solicitação para preservar o estado do cliente.
2. Por segurança, precisamos adicionar uma informação de cabeçalho a cada solicitação.

Métodos HTTP suportados pelo REST:

GET: / string / someotherstring É idempotente e, idealmente, deve retornar os mesmos resultados toda vez que uma chamada é feita

PUT: O mesmo que GET. Idempotent e é usado para atualizar recursos.

POST: deve conter um URL e um corpo Usado para criar recursos. Idealmente, várias chamadas devem retornar resultados diferentes e criar vários produtos.

DELETE: Usado para excluir recursos no servidor.

CABEÇA:

O método HEAD é idêntico ao GET, exceto que o servidor NÃO DEVE retornar um corpo da mensagem na resposta. As informações meta contidas nos cabeçalhos HTTP em resposta a uma solicitação HEAD DEVEM ser idênticas às informações enviadas em resposta a uma solicitação GET.

OPÇÕES:

Esse método permite ao cliente determinar as opções e / ou requisitos associados a um recurso ou os recursos de um servidor, sem implicar uma ação de recurso ou iniciar uma recuperação de recurso.

Respostas HTTP

Vá aqui para todas as respostas .

Aqui estão alguns importantes: 200 - OK 3XX - Informações adicionais necessárias do cliente e redirecionamento de URL 400 - Solicitação
incorreta 401 - Não autorizado a acessar
403 - Proibido
A solicitação era válida, mas o servidor está recusando a ação. O usuário pode não ter as permissões necessárias para um recurso ou pode precisar de uma conta de algum tipo.

404 - Não encontrado
O recurso solicitado não pôde ser encontrado, mas pode estar disponível no futuro. Pedidos subsequentes do cliente são permitidos.

405 - Método não permitido Não há suporte para um método de solicitação para o recurso solicitado; por exemplo, uma solicitação GET em um formulário que exige que os dados sejam apresentados via POST ou uma solicitação PUT em um recurso somente leitura.

404 - Solicitação não encontrada
500 - Falha no servidor interno
502 - Erro de gateway incorreto

HTTP é um protocolo de comunicação que transporta mensagens pela rede. SOAP é um protocolo para trocar mensagens baseadas em XML que podem usar HTTP para transportar essas mensagens. Rest é um protocolo para trocar mensagens (XML ou JSON) que podem usar HTTP para transportar essas mensagens.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style que pode usar HTTP, FTP ou outros protocolos de comunicação, mas é amplamente usado com HTTP.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, é mais comumente usado na API REST apenas porque REST was inspired by WWW (world wide web) which largely used HTTPantes da definição do REST, é mais fácil implementar o estilo da API REST com HTTP.

There are three major constraints in REST (but there are more):

1. A interação entre servidor e cliente deve ser descrita apenas via hipertexto.

2.Servidor e cliente devem ser fracamente acoplados e não fazer suposições entre si. O cliente deve conhecer apenas o ponto de entrada do recurso. Os dados de interação devem ser fornecidos pelo servidor na resposta.

3.O servidor não deve armazenar nenhuma informação sobre o contexto da solicitação. As solicitações devem ser independentes e idempotentes (significa que se a mesma solicitação for repetida infinitamente, exatamente o mesmo resultado será recuperado)

E o HTTP é apenas um protocolo de comunicação (uma ferramenta) que pode ajudar a conseguir isso.

Para mais informações, verifique estes links:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

O REST não está necessariamente vinculado ao HTTP . Os serviços da web RESTful são apenas serviços da web que seguem uma arquitetura RESTful.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

De Você não sabe a diferença entre HTTP e RESTO

Portanto, a arquitetura REST e o protocolo HTTP 1.1 são independentes um do outro, mas o protocolo HTTP 1.1 foi construído para ser o protocolo ideal para seguir os princípios e restrições do REST. Uma maneira de observar o relacionamento entre HTTP e REST é que REST é o design e HTTP 1.1 é uma implementação desse design.

APIs REST devem ser baseadas em hipertexto

No blog de Roy Fielding, aqui estão algumas maneiras de verificar se você está criando uma API HTTP ou uma API REST:

Designers de API, observe as seguintes regras antes de chamar sua criação de API REST:

• Uma API REST não deve depender de nenhum protocolo de comunicação único, embora seu mapeamento bem-sucedido para um determinado protocolo possa depender da disponibilidade de metadados, escolha de métodos etc. Em geral, qualquer elemento de protocolo que use um URI para identificação deve permitir qualquer esquema de URI a ser usado para essa identificação. [Falha aqui implica que a identificação não está separada da interação.]
• Uma API REST não deve conter nenhuma alteração nos protocolos de comunicação além de preencher ou corrigir os detalhes de bits subespecificados dos protocolos padrão, como o método PATCH do HTTP ou o campo do cabeçalho Link. As soluções alternativas para implementações quebradas (como os navegadores estúpidos o suficiente para acreditar que o HTML define o conjunto de métodos do HTTP) devem ser definidas separadamente, ou pelo menos em apêndices, com a expectativa de que a solução alternativa seja obsoleta. [Falha aqui implica que as interfaces de recursos são específicas de objetos, não genéricas.]
• Uma API REST deve gastar quase todo o seu esforço descritivo na definição do (s) tipo (s) de mídia usado para representar recursos e direcionar o estado do aplicativo, ou na definição de nomes de relações estendidos e / ou marcação ativada por hipertexto para os tipos de mídia padrão existentes. Qualquer esforço despendido para descrever quais métodos usar em quais URIs de interesse deve ser totalmente definido dentro do escopo das regras de processamento para um tipo de mídia (e, na maioria dos casos, já definido pelos tipos de mídia existentes). [Falha aqui implica que informações fora de banda estão gerando interação em vez de hipertexto.]
• Uma API REST não deve definir nomes ou hierarquias de recursos fixos (um acoplamento óbvio de cliente e servidor). Os servidores devem ter liberdade para controlar seu próprio espaço para nome. Em vez disso, permita que os servidores instruam os clientes sobre como construir URIs apropriados, como é feito em formulários HTML e modelos de URI, definindo essas instruções nos tipos de mídia e nas relações de vínculo. [Falha aqui implica que os clientes estão assumindo uma estrutura de recursos devido a informações fora da banda, como um padrão específico de domínio, que é o equivalente orientado a dados ao acoplamento funcional da RPC].
• Uma API REST nunca deve ter "digitado" recursos significativos para o cliente. Os autores das especificações podem usar tipos de recursos para descrever a implementação do servidor atrás da interface, mas esses tipos devem ser irrelevantes e invisíveis para o cliente. Os únicos tipos significativos para um cliente são o tipo de mídia da representação atual e os nomes de relação padronizados. [idem]
• Uma API REST deve ser inserida sem conhecimento prévio além do URI inicial (marcador) e conjunto de tipos de mídia padronizados que são apropriados para o público-alvo (ou seja, espera-se que seja entendido por qualquer cliente que possa usar a API). A partir desse ponto, todas as transições de estado do aplicativo devem ser conduzidas pela seleção do cliente de opções fornecidas pelo servidor que estão presentes nas representações recebidas ou implícitas pela manipulação do usuário dessas representações. As transições podem ser determinadas (ou limitadas por) o conhecimento do cliente sobre os tipos de mídia e os mecanismos de comunicação de recursos, os quais podem ser aprimorados em tempo real (por exemplo, código sob demanda). [Falha aqui implica que informações fora de banda estão gerando interação em vez de hipertexto.]