Serviço da web REST vs RESTful vs “normal”

21

Li algumas definições e discussões sobre aplicativos REST e / ou RESTful, mas ainda não entendo o real significado disso.

Normalmente, trabalho com aplicativos que buscam dados via GET ou enviam dados via POST para algum serviço da Web (geralmente um script PHP) que obtém dados do banco de dados ou escreve no banco de dados.

Agora, este é um aplicativo RESTful? Caso contrário, o que seria um aplicativo RESTful? Qual é a diferença entre o conceito RESTful e o conceito com o qual trabalhei até agora? Por favor, explique através de um exemplo.

Além disso, alguém está falando sobre o REST e alguém sobre aplicativos RESTful. Descobri que o termo REST se refere ao conceito teórico, enquanto RESTful é usado quando falamos sobre o aplicativo específico. Isso está certo ou há diferenças reais entre aplicativos REST e RESTful?

— deviDave
fonte

1

Se você puder criar todos os seus Servlets para extrair informações dos parâmetros GET ou POST SOMENTE (absolutamente nada salvo localmente antes da chamada), estará aplicando corretamente o REST. Em outras palavras, o servidor desempenha o papel do modelo no MVC, pois ele não está no controle, mas simplesmente usa o que é fornecido para executar alguma tarefa. Espero que isso explique um pouco melhor.

— Neil

@ Neil Estou do outro lado - aplicativo móvel. É um cliente que utiliza serviço da web e se comunica com ele via POST e GET. Todos os serviços da web foram criados por outra pessoa e tudo o que fiz foi usá-los. Mas a terminologia me confundiu. Então, se estou usando o canal HTTP e os objetos HttpGet / HttpPost, estou lidando com um aplicativo RESTful, certo?

— DeviDave 23/04

Não necessariamente. Não há como saber se é um aplicativo RESTful se você não souber como o servidor é feito, pois pode violar algumas restrições. Dito isto, provavelmente é RESTful se retornar resultados consistentes.

— Neil

@ Neil Oh, eu entendo agora. O RESTful é feito no servidor. E se eu enviar um objeto de postagem com uma solicitação (não cada parâmetro individualmente), provavelmente é uma abordagem REST. Quanto ao cliente (aplicativo móvel), ele não se importa se é REST ou não, pois a codificação é a mesma. Eu entendi direito?

— DeviDave

2

RESTful é servidor e cliente, mas se você puder apenas vê-lo, poderá saber se o cliente segue as restrições. Foi tudo o que eu quis dizer. O que quero dizer com REST é que, se você precisar fazer login, publique nome de usuário e senha. O servidor valida o login e salva a chave de hash do usuário no banco de dados e a retorna. Agora, sempre que você precisar executar uma operação que exija login, sempre passe a chave de hash do usuário. O servidor "esquece" que você fez login, mas usa o hash do usuário para validar seu estado de login. Se não fosse RESTful, o servidor lembrará que você está logado. Entendeu a diferença?

— 213 Neil

13

Os principais atributos de um aplicativo RESTful são: Toda a comunicação é via http GET, POST, PUT, DELETE E todos os itens são endereçados através de um URL padrão do formulário, http://your.site.com/salesapp/salesperson/0000001/detailsou seja, apenas um URL puro sem parâmetros, etc. O URL identifica o que o GET , POST, PUT, DELETE identifica o que você deseja fazer.

A principal razão para fazer isso é que você possui automaticamente um serviço sem estado que pode ser balanceado por carga, realizar failover etc. etc.

A pura simplicidade do esquema cria uma interface muito limpa, dissociando totalmente o cliente de qualquer implementação de back-end específica.

— James Anderson
fonte

Ah, até agora eu não usei PUT ou DELETE (aplicativos móveis geralmente fazem apenas GET e POST), mas isso realmente se parece com o que fiz e estou fazendo no momento. É apenas que os clientes não usam RESTO * termos, mas sim "web service" e "script php"

— deviDave

2

James, você poderia explicar por que os parâmetros de consulta devem ser evitados? Por exemplo, como expresso que desejo que os recursos sejam filtrados de uma maneira específica sem introduzir uma hierarquia falsa?

— Gary Rowe

3

@ GaryRowe: a URL (sem parâmetros) identifica o recurso que você deseja manipular. Você ainda pode ter parâmetros, mas eles não são usados na identificação do recurso. Exemplo: um GET em um diretório (uma URL que termina com /) deve retornar uma lista de recursos no diretório. Um parâmetro no URL pode ser usado para especificar um filtro ou ordem de classificação ou algo parecido.

— Martin York

1

Obrigado, Loki. James pode querer editar sua resposta para refletir isso, pois parece que ele não está permitindo que parâmetros de consulta sejam usados sob nenhuma circunstância que possa ser enganosa. Na verdade, há uma observação interessante de que a lista de recursos em um diretório é em si um recurso que expressa esse conceito.

— Gary Rowe

O REST não exige que o aplicativo seja baseado em URL nem exige que você tenha verbos como GET, POST, DELETE etc. No entanto, para um WebApp, o URL é a única opção e os verbos mencionados acima.

— Nawaz 23/01

6

REST significa Representational State Transfer. Se o seu software estiver em conformidade com as restrições REST , ele será considerado RESTful.

Certo, agora que rasguei descaradamente da Wikipedia, o que isso realmente significa? Isso significa efetivamente o uso de comandos HTTP embutidos, como GET, POST, PUT, DELETE e alguns outros mais raros, para comunicação entre cliente e servidor.

O que você está fazendo parece um aplicativo RESTFul. No entanto, há uma grande diferença entre serviços web RESTFul bem projetados e montados. Por exemplo, o código PHP na outra extremidade do GET pode executar uma mudança de estado, o que seria considerado errado, pois um GET é visto como uma operação somente leitura. Existem diferenças sutis entre como o POST (novo) e o PUT (substituir) também são usados.

O artigo da Wikipedia sobre isso é realmente muito bom, então vou parar por aqui.

— Martijn Verburg
fonte

Até agora, usei GET (HttpGet) para buscar conteúdo e POST (HttpPost) para inserir / alterar o conteúdo de um banco de dados. Enviei isso como um parâmetro para o script HttpPost e PHP no servidor da Web convertido esses parâmetros em código SQL. Este é um aplicativo RESTful? Estou interessado em um conceito, não em como o script PHP foi executado. Eu não fiz isso.

— DeviDave

2

Eu investigaria o uso de PUT no caso em que você está substituindo conteúdo, seu REST mais idiomático do que sempre usando POST.

— 27912 Martijn Verburg

Sim, nesse caso, eu usaria PUT.

— deviDave

+1 por observar que o GET deve ser implementado corretamente (ou seja, é idempotente). Um erro tão fundamental nos primeiros dias.

— Gary Rowe

@deviDave Você também pode procurar no PATCH, projetado para atualizar parte de um recurso. Como Martin ressalta, com razão, PUT é para substituir todo o recurso.

— Gary Rowe

4

Antes de prosseguir, esta pergunta relacionada pode ajudá-lo

A diferença entre REST e RESTful é simplesmente semântica. REST é um estilo de arquitetura aplicado a um relacionamento cliente-servidor. O RESTful é simplesmente uma maneira de informar aos clientes que você usa o REST.

Muitos aplicativos da Web afirmam ser RESTful, mas na verdade são apenas parcialmente conformes às restrições REST (como Martijn Verburg também referenciou em sua resposta). Vou apenas listá-las aqui, mas peço que você leia o artigo:

Servidor cliente
Armazenável em cache
Sistema em camadas
Código sob demanda (opcional)

Como você menciona que trabalha no lado do cliente, pode ser útil ver o que uma arquitetura REST fornecerá e esperará de você como cliente conectado. Embora o REST não seja HTTP, ele é, de longe, o protocolo mais popular que suporta o que é REST, portanto, moldarei meu exemplo em torno disso.

Seu cliente deverá:

use verbos HTTP (por exemplo, GET, POST, PUT, DELETE, OPTIONS, PATCH) para executar operações relevantes
oferta Aceitar cabeçalhos e entender cabeçalhos de tipo de conteúdo (por exemplo, você recebe um XML que nunca viu antes, mas pode usar um XSD referenciado para criar um modelo de domínio do lado do cliente para apresentar ao usuário)
siga os links oferecidos em um tipo de conteúdo que você entende (por exemplo, faça com que seu usuário ou seu aplicativo deduza que <link rel="pay" href="http://example.org/orders(1)/payment"> em HTML expressa uma transição de estado para criar um recurso de pagamento por meio de um POST com um corpo contendo algum XML que representa os detalhes de pagamento, como número do cartão de crédito , quantidade e assim por diante)
reagir corretamente à ampla variedade de códigos de status HTTP

Se ele fizer o que foi descrito acima, pode ser considerado um cliente REST, convém chamá-lo de "aplicativo RESTful", mas isso implicaria que você estivesse usando REST no lado do cliente, o que é incorreto para evitar o termo.

— Gary Rowe
fonte

3

RESTful significa que a interface é um conjunto de objetos que podem ser lidos e atualizados (e possivelmente excluídos). Ou seja, não há consultas multiparâmetros (apenas o parâmetro é o objeto que você deseja ler) e existe apenas um tipo de operação que altera qualquer coisa no servidor, o upload do novo estado.

Essas limitações garantem que todas as solicitações sejam idempotentes (enviá-las várias vezes não tem nenhum efeito extra em enviá-las uma vez). Isso é importante, porque a rede pode falhar a qualquer momento e não entregar nenhuma solicitação ou resposta e, com solicitações idempotentes, você a envia novamente e não precisa realizar uma recuperação complicada.

— Jan Hudec
fonte

Voto positivo para o 1º parágrafo. Tão conciso. Obrigado!

— DeviDave

Só mais uma coisa, para ver se eu entendi direito. Se eu (meu aplicativo) for um cliente do serviço REST, como cliente não faço caso um serviço seja RESTful ou não, pois minha codificação é sempre a mesma (httpget, httppost, etc.)? Esse princípio é importante apenas para o proprietário de um script / aplicativo de servidor?

— DeviDave 23/04

O REST é uma diretriz para o design da semântica da interface. A tecnologia subjacente é HTTP, independentemente de a interface ser RESTful ou não (mas outras camadas, como XML-RPC ou SOAP, não são relevantes para interfaces RESTful), portanto, você sempre usa o mesmo httpget, httppost etc. Mas você lida com falhas de rede de maneira diferente.

— Jan Hudec

para adicionar, o SMTP é uma interface RESTful, embora use verbos diferentes de GET, PUT etc. e um protocolo subjacente diferente, o conceito é o mesmo - você envia comandos baseados em verbos idempotentes para um servidor.

— Gbjbaanb

Nem todas as solicitações REST são idempotentes. Por exemplo, emitir um POST várias vezes resultará em muitos novos recursos.

— Gary Rowe

Serviço da web REST vs RESTful vs “normal” - o mesmo ou não?