Portanto, um serviço RESTful possui um conjunto fixo de verbos em seu vocabulário. Um serviço da Web RESTful os utiliza dos métodos HTTP. Existem algumas supostas vantagens em definir um vocabulário fixo, mas eu realmente não entendo o ponto. Talvez alguém possa explicar isso.

Por que um vocabulário fixo, conforme descrito pelo REST, é melhor do que definir dinamicamente um vocabulário para cada estado? Por exemplo, a programação orientada a objetos é um paradigma popular. O RPC é descrito para definir interfaces fixas, mas não sei por que as pessoas assumem que o RPC é limitado por essas restrições. Poderíamos especificar dinamicamente a interface, assim como um serviço RESTful descreve dinamicamente sua estrutura de conteúdo.

O REST deve ser vantajoso, pois pode crescer sem estender o vocabulário. Os serviços RESTful crescem dinamicamente adicionando mais recursos. O que há de errado em estender um serviço especificando dinamicamente um vocabulário por objeto? Por que não usamos apenas os métodos definidos em nossos objetos como vocabulário e nossos serviços descrevem ao cliente o que são esses métodos e se eles têm ou não efeitos colaterais?

Essencialmente, sinto que a descrição de uma estrutura de recursos no servidor é equivalente à definição de um vocabulário, mas somos forçados a usar o vocabulário limitado no qual interagir com esses recursos.

Um vocabulário fixo realmente dissocia as preocupações do cliente das preocupações do servidor? Eu certamente tenho que me preocupar com alguma configuração do servidor, normalmente esse é o local dos recursos nos serviços RESTful. Reclamar pelo uso de um vocabulário dinâmico parece injusto, porque precisamos raciocinar dinamicamente como entender essa configuração de alguma maneira. Um serviço RESTful descreve as transições que você pode fazer identificando a estrutura do objeto por meio da hipermídia.

Apenas não entendo o que torna um vocabulário fixo melhor do que qualquer vocabulário dinâmico autoexplicativo, o que poderia facilmente funcionar muito bem em um serviço semelhante a RPC. Esse é apenas um mau raciocínio para o vocabulário limitador do protocolo HTTP?

Reflexão

Apenas para esclarecer meus pensamentos um pouco melhor do que eu fiz. Suponha que você esteja criando uma API de uso geral, talvez nem mesmo voltada para a web. Você ficaria feliz se alguém dissesse que você só pode usar esses nomes de métodos em seus objetos? O REST não se restringe ao HTTP, mas considere a situação em que todas as APIs que você escreve, voltadas para a Web ou simplesmente consistem em objetos que contêm os métodos GET POST PUT e DELETE. Portanto, esse método object.foo que você deseja definir não é possível. Você precisa definir um novo objeto chamado foo e chamar seu método GET. É basicamente assim que o REST funciona, e me deixa um pouco desconfortável pensar nisso. Você não tem um entendimento genérico melhor do que o foo faz, apenas foi forçado a criar um novo objeto para o que é essencialmente um método em um objeto pai. Além disso, sua API não é menos complexa, você acabou de ocultar a complexidade da interface criando mais objetos. Os serviços web RESTful nos forçam a adotar uma interface que pode ou não ser suficiente no contexto da API que estamos expondo. Talvez haja um bom motivo para fazer isso com APIs voltadas para a Web, mas um bom motivo para não adotar interfaces padrão para todos os objetos em todas as APIs de uso geral. Um exemplo prático seria apreciado.

A terminologia "verbo" e "substantivo" é um tanto infeliz aqui. Como você já mencionou, você pode criar facilmente objetos para funções. Todas as linguagens orientadas a objetos, exceto Java, têm essa transformação incorporada e, em Java, você acaba fazendo isso o tempo todo, acabando com muitos objetos com um único método e geralmente chamado "invocar", "executar", "aplicar" ou algo assim. (então são as linguagens de programação em que a distinção "verbo" / "substantivo" na verdade não faz sentido).

Os "verbos" do REST são mais como classificar seus métodos para getters, setters (deleters; podem ser considerados tipos de setters) e outros. E tentando fazer tudo com getters e setters. A razão para isso é:

1. Semântica mais fácil diante da falha de comunicação, pois os getters e os setters são idempotentes. Obter o recurso duas vezes não tem efeito adicional e nem defini-lo com o valor que já possui.
2. Definindo algumas semânticas que podem ser usadas possivelmente armazenando em cache o proxy que não entende a interface específica. Os getters são armazenados em cache e os setters invalidam o cache.

O HTTP foi projetado desde o início com os caches e a tolerância a falhas em mente; portanto, esses dois pontos levam a quatro métodos básicos:

• GETé um getter. Supõe-se que não modifique o estado do servidor e retorne o mesmo valor todas as vezes com possibilidade de especificar políticas de expiração e revalidação.
• PUTe DELETEsão o setter e deleter (= setter com zero). Eles normalmente não são usados ​​no contexto da Web normal, mas fazem sentido para o REST.
• POST é uma pia de cozinha genérica "invocar" para a qual caches não podem assumir nada.

O REST é um padrão de design que descreve como usar HTTP bruto ou protocolos de rede semelhantes para implementar a interface que permite o fácil gerenciamento de falhas através de novas tentativas simples e funciona bem com proxies de cache.

Não corresponde facilmente à API de programação regular orientada a objetos. Eu acho que é realmente uma coisa boa. Os desafios da interface através da rede, que é inerentemente não confiável e onde as viagens de ida e volta são muito mais lentas do que a transferência de uma quantidade moderada de dados exige uma abordagem de design diferente da API em processo; portanto, quando parece diferente, as pessoas não tentam aplicar experiência inválida do outro domínio tanto (que é a desgraça do SOAP, XML-RPC e tal; parece chamadas de procedimento, mas não funciona assim e acaba sendo difícil de trabalhar).

A idéia essencial é que a complexidade seja expressa através da representação de recursos e, portanto, verbos adicionais não são necessários. Como alguns colocaram - "No REST, os substantivos são bons, os verbos são ruins."

Se você observar os quatro verbos REST, eles poderão ser mapeados para as operações básicas de CRUD, permitindo essencialmente que você faça o que quiser com seus recursos. Isso é -

POST - Crie o recurso

GET - Leia o recurso

PUT - Atualize o recurso

DELETE - Exclua o recurso

O que mais você precisa?

Considere uma linguagem em que todas as construções (como funções) sejam objetos. Os verbos RESTful estão simplesmente chamando convenções e instruções de atribuição. Para JavaScript, você pode definir uma sintaxe de verbo fixa como INVOKE para chamar uma função, DELETE (o mesmo que excluir em js) para excluir um objeto em outro objeto, SET para atribuir um valor e RETURN para retornar um valor. Poderíamos usar os verbos HTTP para significar a função equivalente de chamada POST, PUT - atribuir valor, GET - retornar um valor, - DELETE - excluir um objeto. Fui pego na ideia de que os métodos HTTP estavam realmente descrevendo métodos de objetos, interfaces de objetos reais, que não consegui descrever que eles realmente descreviam conceitos de nível muito inferior, como as construções básicas da linguagem que são claramente fixas e finitas em todos os aspectos. idiomas sãos.

E é claro que é útil que o roteamento / proxy tenha um vocabulário fixo para refletir.

• Porque um programador profissional antecipa centenas, senão milhares de nomes de métodos. O que parece inútil em um pequeno menor pode ser um grande negócio à medida que o aplicativo se torna maior.

• Porque não há necessidade de padrões sobre nomes de métodos quando eles já estão definidos.

• Porque o principal objetivo do código é legível sem essas traduções adicionais.

• Porque incentiva e auxilia na identificação de 'quando' outra classe deve ser dividida.

• Quando você assume o código, é razoável e realmente possível entender o que e como ele o faz muito mais rapidamente.

• Ele fornece um vocabulário comum e, portanto, um nível de abstração para que você possa se concentrar em outros detalhes e ver padrões.

• Isso facilita a localização de bugs, pois códigos e abordagens comuns podem ser facilmente verificados.

• Quando você trabalha com várias 'camadas', como é o caso do desenvolvimento da Web, saber quais URLs correspondem a quais nomes de ação é muito útil para depuração.

No geral, você nem sempre 'precisa', mas, como a maioria dos padrões, faz muito sentido tentar usá-lo!

A alternativa é algo horrível: WSDL (também conhecido como Web Service Definition Language), que é uma maneira (desajeitada) de descrever programaticamente (um pouco) APIS arbitrário.

O REST limita severamente os verbos, colocando quase toda a variação específica do aplicativo na carga útil do documento. O benefício de fazer isso é que muitas implementações de clientes podem se comunicar com muitos serviços heterogêneos. Os clientes e servidores podem ser completamente desconhecidos um do outro, alguns ainda não foram gravados.

Há um podcast no qual Stefan Tilkov explica bem o REST .

Sim, uma API de descanso possui um conjunto fixo de verbos, mas não precisa se limitar a (ou incluir GET, POST, PUT, DELETE). Eu consideraria GET, POST, PUT, DELETE como uma implementação padrão do REST que funciona para 80% de todos os sistemas existentes.

Outros sistemas que estão implementando mais do que operações brutas podem (e fazem) implementar seus próprios verbos para suas APIs REST. Verbos como Publicar, Consumir, Classificar, Comentar, Pesquisar, Procurar podem ser adicionados e implementados em um sistema REST. Enquanto alguns podem dizer que um vocabulário maior pode torná-lo mais complicado, minha resposta é que depende. Se o seu usuário-alvo for um técnico que entenda o que é um POST, sim, pode ser mais complicado; no entanto, se os usuários de destino da sua API são pessoas reais (ou seja, pessoas que não codificam e não sabem o que é um POST), os verbos reais são muito mais fáceis de usar. De fato, ter um conjunto apropriado de verbos para sua API ajuda a manter os URLs curtos (o que é importante se você quiser que os usuários os digitem em um navegador. Se você usa um vocabulário personalizado, você ' gostaria de ter certeza de que sua API e seus verbos estão bem documentados. Ao usar uma API REST customizada, você deseja garantir que suas 'ações somente leitura' sejam um HTTP GET e 'escreva ações' com POST.

A rede social para adolescentes, Piczo.com, (que descanse em paz) apresentava uma API REST estendida (incluindo os verbos mencionados acima) que foi implementada em 7 idiomas diferentes!

Simples é bom.

Há casos em que você precisa de verbos e complexidade extras, mas a maioria dos problemas pode ser reduzida a ações CRUD simples em recursos, e é isso que o REST tenta promover. Quando você pensa na maioria dos aplicativos Web, no final, eles lêem e mantêm registros em um armazenamento de dados, que usam as mesmas ações muito simples.

object.foo () é bom, mas o que faz? O que está retornando? Está modificando o estado do objeto ou alguma de suas dependências? Você pode chamá-lo duas vezes e obter o mesmo resultado ou isso lhe dará dois valores diferentes? Se você também tiver object.bar (), eles precisam ser chamados em uma ordem específica?

Há muito conhecimento necessário no uso de uma API avançada, e eles geralmente têm suas próprias convenções (por exemplo, o setFoo vai mudar o objeto, o getBar provavelmente é idempotente, dispose () ou destroy () significa que não há outras chamadas no mesmo objeto será possível, etc ...)