O que é REST? Um pouco confuso [fechado]

Eu estava no pressuposto de que o REST era um serviço da Web, mas parece que estou incorreto ao pensar nisso - então, o que é o REST?

Eu li a Wikipedia, mas ainda não consigo entender direito. Por que muitos lugares se referem às APIs como APIs REST?

O REST não é um serviço da Web específico, mas um conceito de design (arquitetura) para gerenciar informações de estado. O artigo seminal sobre isso foi a dissertação de Roy Thomas Fielding (2000), "Estilos arquitetônicos e o design de arquiteturas de software baseadas em rede" ( disponível on - line na Universidade da Califórnia, Irvine).

Leia pela primeira vez o post de Ryan Tomayko. Como expliquei o REST para minha esposa ; é um ótimo ponto de partida. Em seguida, leia a dissertação real de Fielding. Não é tão avançado nem longo (seis capítulos, 180 páginas)! (Eu sei que vocês na escola gostam muito).

EDIT: Eu acho que é inútil tentar explicar o REST. Tem tantos conceitos como escalabilidade, visibilidade (sem estado), etc., que o leitor precisa entender, e a melhor fonte para entender isso é a dissertação real. É muito mais do que POST / GET etc.

REST é um padrão de design de software normalmente usado para aplicativos da web. Nos termos dos leigos, isso significa que é uma ideia comumente usada em muitos projetos diferentes. Significa REpresentational State Transfer . A idéia básica do REST é tratar objetos no lado do servidor (como nas linhas de uma tabela de banco de dados) como recursos que podem ser criados ou destruídos.

A maneira mais básica de pensar sobre o REST é como formatar os URLs de seus aplicativos da web. Por exemplo, se seu recurso foi chamado "postagens", então:

/posts Seria como um usuário acessaria TODAS as postagens, para exibição.

/posts/:id Seria como um usuário acessaria e visualizaria uma postagem individual, recuperada com base em seu ID exclusivo.

/posts/new Seria como você exibia um formulário para criar uma nova postagem.

O envio de uma solicitação POST /usersseria como você realmente criaria uma nova postagem no nível do banco de dados.

O envio de uma solicitação PUT /users/:idseria como você atualizaria os atributos de uma determinada postagem, novamente identificados por um ID exclusivo.

O envio de uma solicitação DELETE /users/:idseria como você excluiria uma determinada postagem, novamente identificada por um ID exclusivo.

Pelo que entendi, o padrão REST foi popularizado principalmente (para aplicativos da web) pela estrutura Ruby on Rails, o que coloca uma grande ênfase nas rotas RESTful. Eu poderia estar errado sobre isso.

Talvez eu não seja o mais qualificado para falar sobre isso, mas foi assim que aprendi (especificamente para o desenvolvimento do Rails).

Quando alguém se refere a uma "API REST", geralmente o que eles querem dizer é uma API que usa URLs RESTful para recuperar dados.

RESTé um estilo arquitetônico e um design para arquiteturas de software baseadas em rede.

RESTconceitos são referidos como recursos. Uma representação de um recurso deve ser sem estado. É representado através de algum tipo de mídia. Alguns exemplos de tipos de mídia incluem XML, JSONe RDF. Os recursos são manipulados pelos componentes. Os componentes solicitam e manipulam recursos por meio de uma interface uniforme padrão. No caso do HTTP, esta interface é constituído por operações padrão de HTTP por exemplo GET, PUT, POST, DELETE.

RESTnormalmente é usado HTTP, principalmente devido à simplicidade do HTTP e seu mapeamento muito natural para os princípios RESTful. O REST, no entanto, não está vinculado a nenhum protocolo específico.

Princípios fundamentais do REST

Comunicação Cliente-Servidor

As arquiteturas cliente-servidor têm uma separação muito distinta de preocupações. Todos os aplicativos criados no estilo RESTful também devem ser, em princípio, cliente-servidor.

Sem Estado

Cada solicitação do cliente para o servidor requer que seu estado seja totalmente representado. O servidor deve ser capaz de entender completamente a solicitação do cliente sem usar nenhum contexto ou estado da sessão do servidor. Daqui resulta que todo estado deve ser mantido no cliente. Discutiremos a representação sem estado em mais detalhes posteriormente.

Armazenável em cache

As restrições de cache podem ser usadas, permitindo que os dados de resposta sejam marcados como armazenáveis ​​em cache ou impossíveis de serem armazenados. Quaisquer dados marcados como armazenáveis ​​em cache podem ser reutilizados como resposta à mesma solicitação subsequente.

Interface uniforme

Todos os componentes devem interagir através de uma única interface uniforme. Como toda a interação de componentes ocorre por meio dessa interface, a interação com diferentes serviços é muito simples. A interface é a mesma! Isso também significa que as mudanças na implementação podem ser feitas isoladamente. Tais mudanças não afetarão a interação fundamental dos componentes porque a interface uniforme é sempre inalterada. Uma desvantagem é que você está preso à interface. Se uma otimização puder ser fornecida a um serviço específico alterando a interface, você estará sem sorte, pois o REST proíbe isso. Pelo lado positivo, no entanto, o REST é otimizado para a web, daí a incrível popularidade do REST sobre HTTP!

Os conceitos acima representam características definidoras do REST e diferenciam a arquitetura REST de outras arquiteturas, como serviços da web. É útil observar que um serviço REST é um serviço da Web, mas um serviço da Web não é necessariamente um serviço REST.

Consulte esta postagem do blog sobre os principais de design do REST para obter mais detalhes sobre o REST e os princípios acima.

Representa Representational State Transfer e pode significar muitas coisas, mas geralmente quando você está falando sobre APIs e aplicativos, está falando do REST como uma maneira de executar serviços da Web ou obter programas para falar pela Web.

O REST é basicamente uma maneira de se comunicar entre sistemas e faz muito do que o SOAP RPC foi projetado para fazer, mas, embora o SOAP geralmente faça uma conexão, autentique e faça coisas nessa conexão, o REST funciona da mesma maneira que a Web. . Você tem um URL e, quando solicita esse URL, recebe algo de volta. É aqui que as coisas começam a ficar confusas porque as pessoas descrevem a Web como o maior aplicativo REST e, embora tecnicamente correto, isso realmente não ajuda a explicar o que é.

Em poucas palavras, o REST permite que dois aplicativos falem pela Internet usando ferramentas semelhantes às usadas por um navegador da web. Isso é muito mais simples que o SOAP e muito do que o REST faz é dizer: "Ei, as coisas não precisam ser tão complexas".

Vale a pena ler:

• Como expliquei o REST para minha esposa (agora disponível aqui)
• Estilos arquitetônicos e o design de arquiteturas de software baseadas em rede

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

A ideia básica é que, em vez de ter uma conexão contínua com o servidor, você faça uma solicitação, obtenha alguns dados, mostre isso a um usuário, mas talvez não todos, e quando o usuário fizer algo que exija mais dados, ou, para passar alguns para o servidor, o cliente inicia uma mudança para um novo estado.