REST: Salvação ou maldição?

Assuntos Gerais
#1

Segundo o aritgo Dor de cabeça com APIs web: mais regra do que exceção, desenvolvedores têm tido bastante dor de cabeça quando usam API’s web (as destacadas pelo artigo são as do Twitter, Facebook e Google). Notei que as semelhanças entre essas API’s são as de que as três são baseadas em REST. Sei que existem boas práticas REST que podem muito bem contornar esses problemas (como a inserção da versão do serviço na própria URL), mas fica a questão: se as pessoas (ou empresas como o Google , Twitter, Facebook… ) não adotarem essas práticas, o que isso faz de REST?

Em tempo: não sou hater de REST, muito pelo contrário. Acho que é um dos melhores caminhos para se adotar uma das melhores arquiteturas que existe, no caso, shared-nothing. Mas fica a dúvida: REST continua a ser uma boa em caso de API’s abertas, como as mencionadas?

Ressalto: não estou interessado em levantar um debate SOAP x REST (nossa, esses debates já cansaram!!!). Apenas saber como os desenvolvedores que usam REST dentro de suas empresas fazem pra desenvolver esses serviços, e considerar se essas práticas são “sustentáveis” ou não.

#2

Ola,

No meu entendimento as APIs mencionadas não são baseadas em hipermidia portanto não podem ser consideradas exemplos de REST. Nada de errado nisso, apenas estou apontando que geralmente essas empresas tendem a comprometer alguns aspectos da arquitetura REST para seus proprios interesses em seus projetos. Outra coisa, dos problemas mencionados, muitos não tem nada a ver com REST, como falta de exemplos(?), aspectos relacionados ao design da aplicação, a questão da documentação, o que tem a ver a empresa não atualizar a documentação ser problema do REST?

Mas de forma geral acho que desenvolvedores estão satisfeitos com APIs REST, ainda que algumas empresas não tenham o respeito necessário para com os usuários de suas APIs.

Bom, eu não sinto saudade do inferno SOAP.

#3

[quote=moscoso.dev]Ola,

No meu entendimento as APIs mencionadas não são baseadas em hipermidia portanto não podem ser consideradas exemplos de REST. Nada de errado nisso, apenas estou apontando que geralmente essas empresas tendem a comprometer alguns aspectos da arquitetura REST para seus proprios interesses em seus projetos. Outra coisa, dos problemas mencionados, muitos não tem nada a ver com REST, como falta de exemplos(?), aspectos relacionados ao design da aplicação, a questão da documentação, o que tem a ver a empresa não atualizar a documentação ser problema do REST?

Mas de forma geral acho que desenvolvedores estão satisfeitos com APIs REST, ainda que algumas empresas não tenham o respeito necessário para com os usuários de suas APIs.

Bom, eu não sinto saudade do inferno SOAP.[/quote]

Concordo contigo até certo ponto quanto aos serviços serem ou não REST. Quanto a usar hipermidia ou não, eu confesso que não olhei. No entanto, aqui eu observei um ponto em que poucas pessoas se atentam: a diferença entre o teórico e o prático. Se o praticado é feito de determinada maneira durante muito tempo, alguns anos depois aquilo passa a ser o real. Isso quer dizer, por exemplo, que não adianta falar que REST tem que usar hipermidia, que os políticos devem ser honestos ou que o homem e a mulher numa casa devem trabalhar. Se, durante algum tempo, for praticado o contrário, aquilo passa a ser a realidade (e leva muito mais tempo para se voltar à teoria original). Portanto, se os praticantes de REST (principalmente os players grandes, como o citado) não aplicarem de maneira correta a teoria, e continuarem espalhando que aquilo é REST, logo será algo que não será viável justamente pelo fato da teoria estar se perdendo.

E falei especialmente de REST porque pelo menos o ponto do formato das requisições seria facilmente contornado pela dupla SOAP+WSDL, justamente por causa do XML Schema. É óbvio que REST tem uma prática pra isso, que seria colocar a versão do serviço na própria URL, mas se as pessoas não usam essa prática, cai na teoria que mostrei no parágrafo anterior.

Enfim, o ponto onde quero chegar é: as pessoas estão aplicando corretamente REST? Se não, porque?

[]'s

#4

“Bom, eu não sinto saudade do inferno SOAP.” +1

nego gosta mesmo eh de reclamar, uma coisa que ninguem fala eh que a maior parte das APIs que estao ae estao disponiveis gratuitamente, e quando vc concorda com os T&C’s dos caras vc esta automaticamente aceitando que vc nao vai poder processar eles ou coisa parecida, o que eh mais que justo …

outra coisa que deve ser mencionado, eh o fato de que se os caras nao fizessem mudanca nenhuma na API, os mesmos que agora tao criticando por que tao mudando estariam jogando pedras neles reclamando que o servico nao melhora …

e como ja foi dito anteriormente isso nao tem absolutamente nada a ver com REST, e sim da forma que empresa X, Y ou Z oferece acesso aos servicos (relembrando que nao cobram nada na maior parte das vezes)… os problemas encontrados seriam os mesmos se estivessem usando o pre-historico elefante branco que eh o SOAP

outro fator eu vejp como sendo de uma certa forma positiva eh que se a manutencao de certos sistemas eh alta devido as mudancas que ocorrem nas APIs, com certeza tem nego mantendo emprego com isso… se fosse o contrario, bastaria contratar um juca qualquer, e mandar embora quando terminar …

moral da historia eh simples: cavalo dado nao se olha os dentes … quer algo estavel que nao mude, quer que a aPI se ajuste a versao do SEU software? poe a mao no bolso (se uma opcao paga estiver disponivel, caso contrario assuma o risco e pronto) … simples assim.

#5

[quote=balrog]“Bom, eu não sinto saudade do inferno SOAP.” +1

nego gosta mesmo eh de reclamar, uma coisa que ninguem fala eh que a maior parte das APIs que estao ae estao disponiveis gratuitamente, e quando vc concorda com os T&C’s dos caras vc esta automaticamente aceitando que vc nao vai poder processar eles ou coisa parecida, o que eh mais que justo …

outra coisa que deve ser mencionado, eh o fato de que se os caras nao fizessem mudanca nenhuma na API, os mesmos que agora tao criticando por que tao mudando estariam jogando pedras neles reclamando que o servico nao melhora …

e como ja foi dito anteriormente isso nao tem absolutamente nada a ver com REST, e sim da forma que empresa X, Y ou Z oferece acesso aos servicos (relembrando que nao cobram nada na maior parte das vezes)… os problemas encontrados seriam os mesmos se estivessem usando o pre-historico elefante branco que eh o SOAP

outro fator eu vejp como sendo de uma certa forma positiva eh que se a manutencao de certos sistemas eh alta devido as mudancas que ocorrem nas APIs, com certeza tem nego mantendo emprego com isso… se fosse o contrario, bastaria contratar um juca qualquer, e mandar embora quando terminar …

moral da historia eh simples: cavalo dado nao se olha os dentes … quer algo estavel que nao mude, quer que a aPI se ajuste a versao do SEU software? poe a mao no bolso (se uma opcao paga estiver disponivel, caso contrario assuma o risco e pronto) … simples assim.[/quote]

Ahmn… então, acho que não é bem assim. Ninguém lança API’s por ser bonzinho, mas sim porque também é interesse deles: sem API’s, o Twitter seria metade do que é hoje. Então, não vale falar que a API deveria ser paga ou que não deveria ter API, porque se fosse assim, o próprio sistema deles não faria sucesso.

Quanto à mudanças no serviço, é óbvio que são necessárias. Mas REST exige o uso de boas práticas para conseguir abraçar isso sem impactos para o usuário.

[]'s

#6

eu apenas entrei com o chapeu de advogado do diabo, nao creio que todo servico pra ser bom tem que necessariamente ser pago, mas o ponto aqui eh: o fato de todos esses fornecedores de API terem o REST em comum na real nao tem nada a ver com o fato do REST ser bom ou ruim, o problema levantado eh outro: se vc nao tem boas praticas de desenvolvimento, nao importa qual a tecnologia que vc usa … o resultado final vai ser o mesmo: caos !!

#7

Fato. Mas o porém é que esses são os maiores cases de REST para o mundo (só o que faltava era o da Amazon). Se esses players grandes não aplicam boas práticas (entre eles o Google, famoso por sua base teórica forte), o que será de REST? Lembrando da teoria que expús um pouco mais acima…

[]'s

#8

[quote=asaudate]
Se o praticado é feito de determinada maneira durante muito tempo, alguns anos depois aquilo passa a ser o real. Isso quer dizer, por exemplo, que não adianta falar que REST tem que usar hipermidia, que os políticos devem ser honestos ou que o homem e a mulher numa casa devem trabalhar. Se, durante algum tempo, for praticado o contrário, aquilo passa a ser a realidade (e leva muito mais tempo para se voltar à teoria original). Portanto, se os praticantes de REST (principalmente os players grandes, como o citado) não aplicarem de maneira correta a teoria, e continuarem espalhando que aquilo é REST, logo será algo que não será viável justamente pelo fato da teoria estar se perdendo. [/quote]

Isso é verdade. Mas se bem que ainda não vejo players espalhando por ai que seus sistemas são REST, no máximo que alguma API é “baseada em REST”. Percebe a diferença?

[quote=asaudate]
E falei especialmente de REST porque pelo menos o ponto do formato das requisições seria facilmente contornado pela dupla SOAP+WSDL, justamente por causa do XML Schema. É óbvio que REST tem uma prática pra isso, que seria colocar a versão do serviço na própria URL, mas se as pessoas não usam essa prática, cai na teoria que mostrei no parágrafo anterior. [/quote]

Poderia explicar melhor isso daí porque versão na própria URL não é uma prática do REST. Porque você precisa fazer isso?

#9

[quote=asaudate]
Fato. Mas o porém é que esses são os maiores cases de REST para o mundo (só o que faltava era o da Amazon). Se esses players grandes não aplicam boas práticas (entre eles o Google, famoso por sua base teórica forte), o que será de REST? Lembrando da teoria que expús um pouco mais acima…

[]'s[/quote]

Você diz além da world wide web?

#10

Repare que a “pesquisa” foi feita por uma integradora de APIs.

Mas é isso mesmo. Quem não quer ter problema de integração então não deve depender de empresas que mudam as regras do jogo sem avisar porque você é um zé ninguém pra elas.

#11

Versão na URL não é uma prática oficializada pelo REST, mas é pregada por Leonard Richardson e Sam Ruby no livro deles, “RESTful Web Services”, justamente para contornar esse tipo de problema. Observe que mudar os dados trafegados é algo necessário, que sempre existiu e sempre vai existir no desenvolvimento de… qualquer coisa. Portanto, aplicar uma regra assim é mais do que necessário se houver o risco de quebrar os clientes dos serviços.

[]'s

#12

[quote=moscoso.dev][quote=asaudate]
Se o praticado é feito de determinada maneira durante muito tempo, alguns anos depois aquilo passa a ser o real. Isso quer dizer, por exemplo, que não adianta falar que REST tem que usar hipermidia, que os políticos devem ser honestos ou que o homem e a mulher numa casa devem trabalhar. Se, durante algum tempo, for praticado o contrário, aquilo passa a ser a realidade (e leva muito mais tempo para se voltar à teoria original). Portanto, se os praticantes de REST (principalmente os players grandes, como o citado) não aplicarem de maneira correta a teoria, e continuarem espalhando que aquilo é REST, logo será algo que não será viável justamente pelo fato da teoria estar se perdendo. [/quote]

Isso é verdade. Mas se bem que ainda não vejo players espalhando por ai que seus sistemas são REST, no máximo que alguma API é “baseada em REST”. Percebe a diferença?
[/quote]

Eu percebo. Mas também teorizo que a massa não percebe a diferença entre “algo baseado” e algo que “é”.

[]'s

#13

Não sei quanto as outras APIs, mas a do Google Maps possui a versão da API na URL e já está na versão 3 mas eles continuam suportando a 2 por exemplo

A do Facebook já encontrei alguns problemas que acho q são bugs, mas não foi bem na camada REST

#14

Esses problema de APIs são conhecidos já. Outra coisa, só por que não é SOAP, não quer dizer que é REST.

URI server pra uma coisa só: identificar recurso. Daí colocam um monte de coisinha lá, não segue o modelo arquitetural…

Me envergonha ver apis que se dizem REST do tipo(exemplo hipotético):

POST | ?action=list&format=xml&entity=person

Por que não um:

GET | /pessoas
Header: Accepts: application/xml

?

Agora minha opinião pessoal é que REST pegou e vai crescer, no PW mesmo tem muitas estatísticas disso. Não há dúvidas que já dominou e é a opção número 1 quando alguém pensa em disponibilizar as funcionalidades de sua aplicação para o povo.

Os argumentos do pessoal de SOAP eram muito fracos IMO, não me levem a mal. Não gosto dessa coisa SOAP cheio de .java gerados, XSD, padrões de dezenas de folhas… Quem gosta de SOAP são as grandes empresas e suas soluções de WS kkkk

Há um tempo eu fazia freela criando APIs, criei só três na vdd e feriam vários princípios do REST, e foi uma satisfação imensa poder dar uma solução simples para problemas que me chegavam como sendo complicados.

Olha um case na minha pouca experiência:

Uma pessoa queria que a app dela estivesse no celular urgente, do dia pra noite, no android, iphone e ainda a possibilidade de um sistema interno deles também acessar os dados. Me chegaram com isso em uma sexta pra na segunda ter já o projeto planejado. Respondi com uma tabela com as URIs, formatos e os métodos HTTP.

A primeira dúvida foi se o cara do android e o do Objective C iam conseguir usar. Respondi que até em linha de comando em um sistema baseado em Unix eles conseguiriam ter uma app :wink:

Não deu outra, projeto aprovado, uma semana pra fazer, dados iam vir de um monte de arquivos CSV que alguém ia colar no diretório X. Em 4 horas tinha um sistema básico usando JAX-RS com a implementação RESTeasy (IMHO a melhor) e testes \o/ Em um dia sistema pronto :slight_smile: Foi uma das semanas mais felizes da minha vida como desenvolvedor hehehehe

No fim tinham um sistema seguro, com autenticação basic do HTTP(adequado para o caso deles), diversos formatos(representações) garantindo interoperabilidade(JSON para Javascript, XML para a turma, YML…) e um WAR pequenino, pronto para deploy em qualquer AS ou Servlet contêiner. É claro que fui sortudo pq não foi algo aberto ao público e não tive mais questões de infraestrutura (database, autenticação mamão com açucar, etc), mas acho que é um caso interessante para mostrar por que acho que REST fica aqui por muito tempo.
Para abrir a API deles, pq tinham planos futuro para isso, deixei um interceptor no esquema para pegar uma API key que eles forneceriam para o cliente se necessário, nada demais. E como documentação, só a tabelinha que fiz inicialmente seria necessária :slight_smile:

Também acredito que o Xiismo do REST está acabando aos poucos. O Twitter feria o REST qdo mexi com ele, mas e daí? Quem se importa? O negócio funciona e é fácil de usar. Eu prefiro seguir o quanto puder os príncipios, mas não acho que colocar .xml|.json na URI vai destruir a API, só não pode fazer o GET |?action=atualizarCliente (inseguro usando um método que deve ser seguro, sem identificação e com tunelamento http) lol

#15

Jesuino, bom saber que deu certo assim! :slight_smile: A idéia era mesmo saber da experiência do pessoal se REST está sendo viável ou não. Vou te confessar que não tenho nada, nada mesmo, contra SOAP, mas sei muito bem que há casos e casos. E é bom saber que REST está conseguindo superar certas barreiras, como a falta de discernimento (já vi muito do caso citado por você : “&action=incluirUsuario”).

[]'s

#16