REST ou RESTful?
Uma dúvida que tive a uns 10 anos quando comecei a estudar REST era:
Por que as vezes via o termo REST e as vezes RESTful?
Para nós brasileiros é muito comum acharmos que se trata de RESTFull, (com 2 L) … nosso cérebro interpreta como (cheio de REST rs). Mas não é que dessa vez ele não está tão errado?!
Em uma pesquisa rápida no google (sim, se você tinha essa dúvida precisa vencer a preguiça! Uma rápida pesquisa resolveria sua dúvida em menos de 10 minutos 😉) descobre-se o seguinte:
Entenda que o REST é uma arquitetura de desenvolvimento que trabalha com protocolo Web. Já o RESTful é um serviço web que utiliza o REST quando implementamos Web Services. …
Forum devmedia
Dai, pensando mais um pouco, caiu a ficha …. o sufixo ‘ful‘ …. por que não pensei nisso antes? Pesquisando mais um pouco e, se você fala inglês, fica tão obvio que chega a dar vergonha de não ter percebido antes ….
Origem do Termo
REST – Substantivo
Se colocarmos o sufixo ‘ful‘, vira um adjetivo, representando ‘presença de’
Se colocarmos o sufixo ‘less‘ vira outro adjetivo, representando ‘ausência de’
Similar ao substantivo Care (cuidado)
Se colocarmos o sufixo ‘ful‘, vira um adjetivo, representando ‘presença de’ – neste caso, cuidadoso
Se colocarmos o sufixo ‘less‘ vira outro adjetivo, representando ‘ausência de’ – neste caso, desastrado, descuidado
Definição
Mas de onde veio o But?! Continua lendo que eu já te conto, mas antes precisamos entender o que é REST:
REST (Representational State Transfer ou Transferência Representacional de Estado) é um estilo arquitetural, proposto por Roy Fielding (um dos criadores do protocolo HTTP, aquele que ninguém usa, só quem usa a internet e mais uns gatos pingados … ) em sua tese de doutorado. Nesta tese ele propõe uma série de regras (constraints) que devemos seguir para usarmos a Web como plataforma de distribuição de serviços.
Muito complicado?
Basicamente ele botou ordem na casa, padronizou várias coisas, para que esta convenção simplifique o entendimento dos serviços expostos. Exigindo menos documentação uma vez que todos seguem o mesmo padrão. Na minha época, os frameworks usavam algo parecido …. chamávamos isso de convention over configuration. Esta prática dispensava muitas configurações caso o desenvolvedor siga a convenção do framework.
Escala de Maturidade
Mais tarde, outro pesquisador propôs uma escala de maturidade para facilitar a adoção e ter uma forma de avaliar a maturidade não vinculada a nenhuma consultoria:
Nesta escala, o nível 0 representa o completo caos, como todo go horser gosta.
Nenhum padrão, afinal de contas, eu não devo satisfação pra ninguém né?! rs
Brincadeiras a parte, muitos analistas que defendiam REST com unhas e dentes na época falavam que era melhor expor serviços em SOAP que em estar neste nível.
Acreditem, isso quer dizer que você não quer estar ai.
POX significa Plain Old XML, também conhecido como RPC.
No nível 1, já vemos as capacidades organizadas por Recursos, ou Resources. Então temos um agrupamento pro entidades, mas suas capacidades (ou métodos) ainda estão despadronizados;
No nível 2, a Uniform Interface é introduzida, padronizando a forma como as capacidades devem ser modeladas.
A grande maioria das APIs que vi até hoje almejam estar neste nível (e poucas realmente conseguem, dependendo de quão rígido você é no julgamento delas)
O nível 3 surge um conceito que até hoje é muito pouco entendido e usado, talvez pelo como não ser bem documentado. Estou falando do Hypermedia. A idéia é ótima, mas vi muito poucas APIs adotando este conceito.
Agora a parte chocante … para o autor do REST, você só pode falar que uma API ou Serviço são RESTful, caso eles estejam no nível 3!
Particularmente acho que isso iria complicar demais as discussões, porque nenhuma API eu fiz até hoje estava no nível 3 …. então não faria mais sentido usar o termo REST. Então eu uso o nível 2 como referência …. e não sou tão criterioso na modelagem dos recursos (nível 1), senão caímos no dilema acima.
Finalmente, RESTbut
Bom, agora que você já está um pouco mais familiarizado com os termos, vamos abordar o RESTbut. O termo mais correto seria RESTless, mas qual seria a graça disso?
Eu jurava que já tinha visto esse termo, mas quando fui pesquisar para escrever este artigo, não achei …
Mas como já tinha botado no título, achei que ficaria mais interessante … e tem muitas similaridades com o scrumbut, que normalmente acompanha o RESTbut.
Assim como seu primo scrumbut, o RESTbut não gosta de muitas regras, e gosta de descartar os principais conceitos do REST, como o a organização por recursos, e principalmente os Verbos (Uniform Interface). Mas sempre encontramos uma versão mais conservadora do RESTbut que mantem os principais conceitos, mas só usa um HTTP Status code, o 200.
Como saber se deu certo? Olha o payload … se o campo result == 0 => sucesso, senão é algum erro, mas calma todos os retornos também tem errorMessage e description.
Bom, acho se você ainda está lendo, é porque se importa com a qualidade do seu trabalho, parabéns! Poucos profissionais fazem isso.
Se o texto está muito complicado, comece a me seguir no Instagram, estou sempre tirando dúvidas de integração nos stories. Se não tem tempo para isso, clique aqui.
