Aparentemente, o REST é apenas um conjunto de convenções sobre como usar o HTTP . Gostaria de saber que vantagem essas convenções oferecem. Alguém sabe?

Eu não acho que você receberá uma boa resposta para isso, em parte porque ninguém realmente concorda com o que é REST . A página da wikipedia é pesada em chavões e leve em explicação. A página de discussão vale uma olhada apenas para ver o quanto as pessoas discordam disso. Até onde eu sei, REST significa isso:

Em vez de ter URLs setter e getter nomeados aleatoriamente e usando GETpara todos os getters e POSTpara todos os setters, tentamos ter as URLs identificar os recursos e, em seguida, usar as ações de HTTP GET, POST, PUTe DELETEpara fazer coisas para eles. Então, ao invés de

GET /get_article?id=1
POST /delete_article   id=1

Você faria

GET /articles/1/
DELETE /articles/1/

E então POSTe PUTcorresponde às operações "criar" e "atualizar" (mas ninguém concorda com o caminho inverso).

Eu acho que os argumentos de cache estão errados, porque as strings de consulta geralmente são armazenadas em cache e, além disso, você realmente não precisa usá-las. Por exemplo, o django facilita algo assim, e eu não diria que era REST:

GET /get_article/1/
POST /delete_article/     id=1

Ou apenas inclua o verbo no URL:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

Nesse caso, GETsignifica algo sem efeitos colaterais e POSTsignifica algo que altera os dados no servidor. Acho que este é talvez um pouco mais clara e fácil, especialmente porque você pode evitar toda a PUTversus POSTcoisa. Além disso, você pode adicionar mais verbos, se quiser, para não ficar artificialmente vinculado ao que o HTTP oferece. Por exemplo:

POST /hide/article/1/
POST /show/article/1/

(Ou seja o que for, é difícil pensar em exemplos até que eles aconteçam!)

Então, em conclusão, existem apenas duas vantagens que posso ver:

1. Sua API da web pode ser mais limpa e fácil de entender / descobrir.
2. Ao sincronizar dados com um site, provavelmente é mais fácil usar o REST, porque você pode apenas dizer o que synchronize("/articles/1/")quer que seja. Isso depende muito do seu código.

No entanto, acho que existem algumas grandes desvantagens:

1. Nem todas as ações são mapeadas facilmente para CRUD (criar, ler / recuperar, atualizar, excluir). Você pode até não estar lidando com recursos de tipo de objeto.
2. É um esforço extra para benefícios duvidosos.
3. Confusão quanto ao caminho PUTe ao redor POST. Em inglês, eles significam coisas semelhantes ("vou colocar / publicar um aviso na parede").

Então, para concluir, eu diria: a menos que você realmente queira fazer um esforço extra ou se o seu serviço for muito bem mapeado para operações CRUD, salve o REST para a segunda versão da sua API.

Acabei de encontrar outro problema com o REST: não é fácil fazer mais de uma coisa em uma solicitação ou especificar quais partes de um objeto composto você deseja obter. Isso é especialmente importante em dispositivos móveis, onde o tempo de ida e volta pode ser significativo e as conexões não são confiáveis. Por exemplo, suponha que você esteja recebendo postagens em uma linha do tempo do facebook. A maneira REST "pura" seria algo como

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

O que é meio ridículo. A API do Facebook é ótima para IMO, então vamos ver o que eles fazem:

Por padrão, a maioria das propriedades do objeto é retornada quando você faz uma consulta. Você pode escolher os campos (ou conexões) que deseja retornar com o parâmetro de consulta "fields". Por exemplo, este URL retornará apenas o ID, nome e foto de Ben: https://graph.facebook.com/bgolub?fields=id,name,picture

Não tenho ideia de como você faria algo assim com o REST e, se o fizesse, ainda contaria como REST. Eu certamente ignoraria qualquer um que tentasse lhe dizer que você não deveria fazer isso (principalmente se o motivo for "porque não é REST")!

Simplificando, REST significa usar HTTP do jeito que deveria ser.

Dê uma olhada na dissertação de Roy Fielding sobre o REST . Eu acho que todas as pessoas que estão desenvolvendo web devem ler.

Como uma observação, Roy Fielding também é um dos principais fatores por trás do protocolo HTTP.

Para citar alguns dos avanços:

• Simples.
• Você pode fazer bom uso do cache HTTP e do servidor proxy para ajudá-lo a lidar com alta carga.
• Ajuda a organizar até um aplicativo muito complexo em recursos simples.
• Isso facilita a utilização de seu aplicativo por novos clientes, mesmo que você não o tenha projetado especificamente para eles (provavelmente porque eles não existiam quando você criou o aplicativo).

Simplificando: NENHUM .

Sinta-se à vontade para fazer voto negativo, mas ainda acho que não há benefícios reais em relação a HTTP não REST. Todas as respostas atuais são inválidas. Argumentos da resposta atualmente mais votada:

• Simples.
• Você pode fazer bom uso do cache HTTP e do servidor proxy para ajudá-lo a lidar com alta carga.
• Ajuda a organizar até um aplicativo muito complexo em recursos simples.
• Isso facilita a utilização de seu aplicativo por novos clientes, mesmo que você não o tenha projetado especificamente para eles (provavelmente porque eles não existiam quando você criou o aplicativo).

1. Simples

Com o REST, você precisa de uma camada de comunicação adicional para os scripts do lado do servidor e do cliente => é realmente mais complicado do que o uso de HTTP não REST.

2. Cache

O armazenamento em cache pode ser controlado por cabeçalhos HTTP enviados pelo servidor. O REST não adiciona nenhum recurso ausente no REST.

3. Organização

O REST não ajuda a organizar as coisas. Ele obriga você a usar API suportado por biblioteca do lado do servidor que você está usando. Você pode organizar seu aplicativo da mesma maneira (ou melhor) quando estiver usando uma abordagem não REST. Por exemplo, consulte Model-View-Controller ou roteamento MVC .

4. Fácil de usar / implementar

Não é verdade. Tudo depende de quão bem você organiza e documenta seu aplicativo. O REST não melhorará magicamente seu aplicativo.

IMHO, a maior vantagem que o REST permite é reduzir o acoplamento cliente / servidor. É muito mais fácil evoluir uma interface REST ao longo do tempo sem interromper os clientes existentes.

Descoberta

Cada recurso tem referências a outros recursos, na hierarquia ou nos links, por isso é fácil navegar. Essa é uma vantagem para o ser humano que está desenvolvendo o cliente, poupando-o de consultar constantemente os documentos e oferecer sugestões. Isso também significa que o servidor pode alterar os nomes dos recursos unilateralmente (desde que o software cliente não codifique os URLs).

Compatibilidade com outras ferramentas

Você pode entrar em qualquer parte da API ou usar o navegador da web para navegar pelos recursos. Facilita a depuração e o teste de integração.

Nomes de verbos padronizados

Permite que você especifique ações sem precisar caçar as palavras corretas. Imagine se getters OOP e setters não foram padronizados, e algumas pessoas usado retrievee defineem vez disso. Você precisaria memorizar o verbo correto para cada ponto de acesso individual. Sabendo que há apenas alguns verbos disponíveis, contadores desse problema.

Status padronizado

Se você GETpossui um recurso que não existe, pode ter certeza de obter um 404erro em uma API RESTful. Compare-o com uma API não RESTful, que pode retornar {error: "Not found"}envolto em Deus, sabe quantas camadas. Se você precisar de espaço extra para escrever uma mensagem para o desenvolvedor do outro lado, sempre poderá usar o corpo da resposta.

Exemplo

Imagine duas APIs com a mesma funcionalidade, uma após REST e a outra não. Agora imagine os seguintes clientes para essas APIs:

Repousante:

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP:

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

Agora pense nas seguintes perguntas:

• Se a primeira chamada de cada cliente funcionou, com que certeza você pode ter o resto também funcionará?

• Houve uma grande atualização na API que pode ou não ter alterado esses pontos de acesso. Quanto dos documentos você terá que reler?

• Você pode prever o retorno da última consulta?

• Você deve editar a revisão publicada (antes de excluí-la). Você pode fazer isso sem verificar os documentos?

Eu recomendo dar uma olhada em Como eu expliquei o descanso de Ryan Tomayko para minha esposa

Edição de terceiros

Trecho do link waybackmaschine:

Que tal um exemplo. Você é professor e deseja gerenciar os alunos:

• em quais aulas eles estão,
• que notas estão recebendo,
• contatos de emergência,
• informações sobre os livros dos quais você ensina etc.

Se os sistemas são baseados na web, então provavelmente há uma URL para cada um dos substantivos envolvidos aqui: student, teacher, class, book, room, etc. ... Se houvesse uma representação legível por máquina para cada URL, seria trivial trancar novas ferramentas no sistema, porque todas essas informações seriam consumíveis de maneira padrão. ... você poderia criar um sistema em todo o país que pudesse conversar com cada um dos sistemas escolares individuais para coletar as notas dos testes.

Cada um dos sistemas obteria informações um do outro usando um simples HTTP GET. Se um sistema precisar adicionar algo a outro sistema, ele usará um HTTP POST. Se um sistema deseja atualizar algo em outro sistema, ele usa um HTTP PUT. A única coisa que resta descobrir é como devem ser os dados.

Eu sugeriria que todos que estão procurando uma resposta para essa pergunta passem por essa "apresentação de slides" .

Eu não conseguia entender o que é REST e por que é tão legal, seus prós e contras, diferenças em relação ao SOAP - mas essa apresentação de slides foi tão brilhante e fácil de entender, por isso está muito mais claro para mim agora do que antes.

Armazenamento em cache.

Existem outros benefícios mais detalhados do REST que giram em torno da capacidade de evolução por meio de acoplamento e hipertexto frouxos, mas os mecanismos de cache são a principal razão pela qual você deve se preocupar com o HTTP RESTful.

Está escrito na dissertação de Fielding . Mas se você não quiser ler muito:

• escalabilidade aumentada (devido a restrições de estado sem cache, cache e sistema em camadas)
• cliente e servidor dissociados (devido a restrições de interface sem estado e uniformes)
  • clientes reutilizáveis ​​(o cliente pode usar navegadores REST gerais e semântica RDF para decidir qual link seguir e como exibir os resultados)
  • clientes sem interrupção (os clientes quebram apenas por alterações semânticas específicas do aplicativo, porque usam a semântica em vez de algum conhecimento específico da API)

• Atribua um ID a cada "recurso"
• Vincular as coisas
• Use métodos padrão
• Recursos com várias representações
• Comunique-se apátrida

É possível fazer tudo apenas com POST e GET? Sim, é a melhor abordagem? Não por que? porque nós temos métodos padrões. Se você pensar novamente, seria possível fazer tudo usando apenas GET .. então por que deveríamos nos preocupar em usar o POST? Por causa dos padrões!

Por exemplo, hoje pensando em um modelo MVC, você pode limitar seu aplicativo a responder apenas a tipos específicos de verbos como POST, GET, PUT e DELETE. Mesmo que tudo seja emulado para POST e GET, não faz sentido ter verbos diferentes para ações diferentes?

A descoberta é muito mais fácil no REST. Temos documentos WADL (semelhantes ao WSDL em serviços tradicionais da web) que ajudarão você a anunciar seu serviço para o mundo. Você também pode usar descobertas UDDI. Com o HTTP POST e GET tradicional, as pessoas podem não conhecer seus esquemas de solicitação e resposta de mensagem para ligar para você.

Uma vantagem é que, podemos processar documentos XML de maneira não sequencial e remover dados XML de diferentes fontes, como objeto InputStream, URL, nó DOM ...

@Timmmm, sobre sua edição:

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

Isso reduziria drasticamente o número de chamadas

E nada impede que você crie um servidor que aceite parâmetros HTTP para indicar os valores de campo que seus clientes podem desejar ...

Mas isso é um detalhe.

Muito mais importante é o fato de você não mencionar enormes vantagens do estilo de arquitetura REST (escalabilidade muito melhor devido à falta de estado do servidor; disponibilidade muito melhor também devido à falta de estado do servidor; uso muito melhor dos serviços padrão, como cache para instância, ao usar um estilo de arquitetura REST; acoplamento muito menor entre cliente e servidor, devido ao uso de uma interface uniforme; etc. etc.)

Quanto à sua observação

"Nem todas as ações são facilmente mapeadas para CRUD (criar, ler / recuperar, atualizar, excluir)."

: um RDBMS também usa uma abordagem CRUD (SELECT / INSERT / DELETE / UPDATE) e sempre há uma maneira de representar e agir sobre um modelo de dados.

Em relação à sua sentença

"Você pode nem estar lidando com recursos de tipo de objeto"

: um design RESTful é, em essência, um design simples - mas isso NÃO significa que o design é simples. Você vê a diferença? Você precisará pensar muito nos conceitos que seu aplicativo representará e manipulará, o que deve ser feito por ele, se você preferir, para representá-lo por meio de recursos. Mas se você fizer isso, terá um design mais simples e eficiente.

As strings de consulta podem ser ignoradas pelos mecanismos de pesquisa.