REST, isto é mesmo necessário? - Dúvidas e Discussão de Programação - Portugal-a-Programar
REST, isto é mesmo necessário?
Por pedrotuga, 21 de Fevereiro de 2009 em Dúvidas e Discussão de Programação
Ultimamente tem andado aí um grande hype em torno de aplicações web com uma arquitectura REST.
Já tinha lido a página da wikipédia sobre o assunto, mas como não é muito completa nem objectiva ficava sempre sem uma ideia claro do que era isto do REST.
Hoje decidi colocar algumas horas da minha vida e fazer umas leituras mais aprofundadas sobre isto. Só valeu a pena por causa de desmistificar isto na minha cabecinha, de resto foi uma perda de tempo.
Ora, falando de aplicações web, de um modo geral, as aplicações bem escritas e desenvolvidas com tecnologias FOSS são em geral RESTFUL sem se preocuparem com isso. Por exemplo as minhas são*, mesmo tendo eu descoberto o significado do acrónimo na sua totalidade apenas hoje.
O exemplo dado na maior parte das vezes é o protocolo HTTP, e depois o contra exemplo dado é o XML-RPC como sendo a pior coisa do mundo porque não é restful. Claro que outras coisas como SOAP são demasiado sexy para ser atacadas da mesma forma que o pobre XML-RPC.
O irónico no meio disto tudo é que, em geral, as aplicações que oferecem uma interface em XML-RPC, são precisamente aquelas que já tinham um design RESTFUL. Em oposição a aplicações desenvolvidas com tecnologias mais bloated que acentam fortemente em padrões próprios e pouco abertos.
Eu confesso que começo a perceber os programadores de LISP quando vão aos arames assim que lhes falam em XML.
Realmente, não era preciso chegarmos a 2009 para estarmos a fazer uma grande orgia em torno de uma coisa que até já existe pelo menos desde 1996 e tem sido extensivamente usada. Excepto provavelmente pelo pessoal que anda agora todo maluco com o REST.
Resumindo e complicando, a minha opinião é esta:
por que raio é que andam agora a pregar ao REST em vez de simplesmente lhe chamarem 'pequenas e óbvias boas práticas de programação'? É que é isso que muito boa gente anda a fazer daqui a mais há 20 anos.
Qual é a vossa opinião àcerca disto tudo? Há por aqu alguem que seja autor de uma aplicação não-RESTFUL?
*Quando digo que as minhas aplicações são RESTFUL estou a referir-me à sua arquitectura. Em 90% da literatura que aí anda, o protocolo HTTP é dado como exemplo e depois acaba por ser metido à bruta de forma atabalhoada no próprio conceito de arquitectura REST, o que não faz qualquer sentido.
Como em tudo é apenas publicidade. Se lhe chamassemos "pequenas e óbvias boas práticas de programação", muito pouca gente iria querer usar , agora dá-lhe um acrónimo e vais ver como a coisa vende!
Acho que o importante é retirar o que é está a servir de base aos acrónimos, o que é realmente importante, e deixar um pouco o hype para quem tem tempo. Olha o web 2.0, os conceitos não são novos, têm apenas um nome catita.
Eu olho para essas questões de uma forma muito simples, ver o que realmente é a tecnologia/arquitectura/etc, o resto é publicidade para vender.
Já agora pedrotuga podias aproveitar para explicar o que te ficou retido depois de tanta leitura sobre o que raio era o REST.
Eu também já li algumas coisas, mas a ideia que fiquei foi tentar desenvolver as aplicações web de forma a que se utilize todas as potencialidades do protoclo HTTP. Gets para mostrar ou listar dados. PUTS para actualizar dados, POSTS para criar, DELETEs para eliminar.
Para mim REST é pouco mais que isto, mas gostava que alguém me explicasse como deve ser...
As chamadas "boas práticas de programação" já cá andam desde quase o princípio. Quem as conhecer será "intemporal". Profissionalmente é preciso ter muito cuidado em ir atrás de "novas modas". Certas coisas precisam de tempo para serem estudas e assimiladas, e as "modas" mudam demasiado depressa. No tempo livre brinco com qualquer tecnologia que me pareça interessante, mas no trabalho tento usar apenas aquilo que domino e conheço muito bem.
Isso é um EXEMPLO de uma arquitectura RESTful mas não é a sua definição.
Uma aplicação RESTful, é basicamente uma aplicação que obedece a alguns princípios:
-Cada recurso deve ter um identificador único
-Qualquer tipo de recurso deve ter um ID
-Tudo são recursos
-A aplicação deve basear-se numa sintaxe que contem a acção, identificação do recurso e opcionalmente outros dados
-Os recursos devem conter ligações para as suas relações
Tirando o último ponto, tudo me parece óbvio para quem desenovlve uma aplicação com pés e cabeça.
O exemplo mais comum é um servidor de HTTP. Obedece a vários urls (identificadores de recursos), cada url supostamente identifica um recursto único, e tem um método para cada uma das acções.
Mas nada impede que se crie um aplicação RESTful sobre HTTP, como é o que a maior parte das frameworks (em particular as que são baseadas no rails) levam o programador a fazer.
Ando um "bocado" fora destas guerrinhas REST vs RPC, mas aqui vai a minha opinião.
Tirando o "Tudo são recursos", nada disso é a definição de REST. O REST opõe-se ao RPC por considerar o webservice uma resource de informação e não um género de máquina-que-faz-determinadas-funções-a-pedido-e-que-retorna-o-resultado-dessa-função (RPC), as simple as that. O REST acaba por ser apenas um nome para webservices que se consideram state-based data-feeders cujos pedidos são feitos usando ao máximo as potencialidades do protocolo que utilizam para transporte (HTTP) em vez de usarem esse protocolo apenas como um meio para transportar resultados (desperdiçando assim potencialidades do mesmo), regra geral em formatos "bloated" (XML no caso do XML-RPC). Cada um tem os seus prós e contras, mas a título pessoal, o REST não é nem mais nem menos prático de implementar do lado do servidor e em nada reduz a complexidade de código necessária no cliente para aceder ao webservice em comparação com um sistema de RPC, a única (e forte) razão que encontro para haver tanta hype à volta dele é mesmo o facto de explorar as potencialidades standard de um protocolo tão usado como o HTTP em vez de reinventar a roda.
Tirácio... entendeste mal o conceito de Rest. Eu tinha alertado precisamente para essa falácia.
Para quem quiser clarificar o conceito da arquitectura na sua cabeça, pode ler a dissertação que introduziu o conceito enquanto conceito (na prática já existia):
REST é uma arquitectura não é uma tecnologia. De resto, o tipo de API que referes que usa os métodos HTTP são APIs RPC, que é como quem diz: chamam de procedimentos remotos. Não usam é o protocolo XML-RPC.
O protocolo XML-RPC não é restful por si só, mas nada impede quem quer que seja de implementar uma API Restful sobre XML-RPC ou qualquer outro protocolo por assim dizer.
Mas vou repetir, O HTTP é apenas um exemplo de um protocolo Restful, uma arquitectura restful não tem que usar HTTP, nem uma API passa a ser restful pelo simples facto de usar HTTP sem outro protocolo de RPC por cima.
O REST acaba por ser apenas um nome para webservices que se consideram state-based data-feeders cujos pedidos são feitos usando ao máximo as potencialidades do protocolo que utilizam para transporte (HTTP) em vez de usarem esse protocolo apenas como um meio para transportar resultados (desperdiçando assim potencialidades do mesmo), regra geral em formatos "bloated" (XML no caso do XML-RPC).
Isto acaba por ser uma consequencia para esse tipo de webservices de facto. Mas olha o caso do HTTP, segundo esta definição seria o exemplo paradigmático de uma protocolo não restful uma vez que existe precisamente para nos abstrairmos do protocolo que este usa para transporte.
Eu sou uma amante dos protocolos RPC e acho que é uma grande ideia. A chegada em força do XML tem permitido grandes avanços em termos de compatibilidades e interoperabilidade. Chamar "bloat" a um formato XML é um pouco injusto. Tudo bem que em muitas situações não é preciso, mas afinal de contas CORBA, SOAP, XML-RPC, etc são formatos standardizados e com suporte para funcionalidades que avançadas que podem ser miuto úteis.