REST vs JSON-RPC? [fechadas]

Estou tentando escolher entre REST e JSON-RPC para desenvolver uma API para um aplicativo da web. Como eles se comparam?

Atualização 2015: Eu achei o REST mais fácil de desenvolver e usar para uma API que é veiculada na Web / HTTP, porque o protocolo HTTP existente e maduro, entendido pelo cliente e pelo servidor, pode ser aproveitado pela API. Por exemplo, códigos de resposta, cabeçalhos, consultas, corpos de postagem, cache e muitos outros recursos podem ser usados ​​pela API sem nenhum esforço ou configuração adicional.

O problema fundamental do RPC é o acoplamento. Os clientes RPC tornam-se fortemente acoplados à implementação de serviços de várias maneiras e fica muito difícil alterar a implementação do serviço sem interromper os clientes:

• Os clientes precisam saber os nomes dos procedimentos;
• Ordem de parâmetros de procedimento, tipos e assuntos de contagem. Não é tão fácil alterar assinaturas de procedimentos (número de argumentos, ordem dos argumentos, tipos de argumentos etc ...) no lado do servidor sem interromper as implementações do cliente;
• O estilo RPC não expõe nada além de pontos de extremidade de procedimento + argumentos de procedimento. É impossível para o cliente determinar o que pode ser feito a seguir.

Por outro lado, no estilo REST, é muito fácil orientar os clientes, incluindo informações de controle nas representações (cabeçalhos HTTP + representação). Por exemplo:

• É possível (e realmente obrigatório) incorporar links anotados com tipos de relação de link que transmitem significados desses URIs;
• As implementações do cliente não precisam depender de nomes e argumentos de procedimentos específicos. Em vez disso, os clientes dependem dos formatos das mensagens. Isso cria a possibilidade de usar bibliotecas já implementadas para formatos de mídia específicos (por exemplo, Atom, HTML, Collection + JSON, HAL etc ...)
• É possível alterar facilmente os URIs sem interromper os clientes, pois eles dependem apenas das relações de link registradas (ou específicas do domínio);
• É possível incorporar estruturas semelhantes a formulários em representações, dando aos clientes a possibilidade de expor essas descrições como recursos da interface do usuário se o usuário final for humano;
• Suporte para armazenamento em cache é uma vantagem adicional;
• Códigos de status padronizados;

Existem muitas outras diferenças e vantagens no lado do REST.

Eu explorei o problema detalhadamente e decidi que o REST puro é muito limitador e o RPC é melhor, mesmo que a maioria dos meus aplicativos seja CRUD. Se você seguir o REST, acabará coçando a cabeça, imaginando como pode adicionar facilmente outro método necessário à sua API para algum propósito especial. Em muitos casos, a única maneira de fazer isso com o REST é criar outro controlador para ele, o que pode complicar indevidamente o seu programa.

Se você decidir sobre o RPC, a única diferença é que você está especificando explicitamente o verbo como parte do URI, que é claro, consistente, com menos bugs e realmente sem problemas. Especialmente se você criar um aplicativo que vai muito além do simples CRUD, o RPC é o único caminho a percorrer. Eu tenho outro problema com os puristas do RESTful: HTTP POST, GET, PUT, DELETE têm significados definidos no HTTP que foram subvertidos pelo REST para significar outras coisas, simplesmente porque eles se encaixam na maioria das vezes - mas não o tempo todo.

Na programação, há muito tempo descobri que tentar usar uma coisa para significar duas coisas acontecerá em algum momento e te morderá. Eu gosto de poder usar o POST para praticamente todas as ações, porque fornece a liberdade de enviar e receber dados conforme seu método precisa. Você não pode encaixar o mundo inteiro em CRUD.

Primeiro, o HTTP-REST é uma arquitetura de "transferência de estado representacional". Isso implica muitas coisas interessantes:

• Sua API ficará sem estado e, portanto, muito mais fácil de projetar (é realmente fácil esquecer uma transição em um autômato complexo) e integrar-se com partes de software independentes.
• Você será levado a projetar métodos de leitura como seguros , fáceis de armazenar em cache e de integrar.
• Você será levado a projetar métodos de gravação como métodos idempotentes , que lidarão muito melhor com os tempos limite.

Segundo, o HTTP-REST é totalmente compatível com HTTP (consulte "seguro" e "idempotente" na parte anterior), portanto, você poderá reutilizar bibliotecas HTTP (existentes para todas as línguas existentes) e proxies HTTP reversos, que fornecerão a você a capacidade de implementar recursos avançados (cache, autenticação, compactação, redirecionamento, reescrita, registro em log etc.) com zero linha de código.

Por último, mas não menos importante, o uso do HTTP como protocolo RPC é um grande erro, de acordo com o designer do HTTP 1.1 (e inventor do REST): http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2

Ótimas respostas - só queria esclarecer alguns dos comentários. O JSON-RPC é rápido e fácil de consumir, mas, como os recursos e parâmetros mencionados, são fortemente acoplados e tendem a depender de verbos (api / deleteUser, api / addUser) usando GET / POST, onde o REST fornece recursos vagamente acoplados (api / usuários) que em uma API REST HTTP se baseiam em vários métodos HTTP (GET, POST, PUT, PATCH, DELETE). O REST é um pouco mais difícil de ser implementado por desenvolvedores inexperientes, mas o estilo tornou-se bastante comum agora e oferece muito mais flexibilidade a longo prazo (dando à API uma vida mais longa).

Além de não ter recursos fortemente acoplados, o REST também permite que você evite ser comprometido com um único tipo de conteúdo - isso significa que se o seu cliente precisar receber os dados em XML, JSON ou YAML - se for incorporado ao seu sistema, você poderá retorne qualquer um que use o tipo de conteúdo / aceite cabeçalhos.

Isso permite que você mantenha sua API flexível o suficiente para suportar novos tipos de conteúdo OU requisitos de cliente.

Mas o que realmente separa o REST do JSON-RPC é que ele segue uma série de restrições cuidadosamente pensadas, garantindo a flexibilidade da arquitetura. Essas restrições incluem garantir que o cliente e o servidor possam evoluir independentemente um do outro (você pode fazer alterações sem atrapalhar o aplicativo do cliente), as chamadas são sem estado (o estado é representado através da hipermídia), uma interface uniforme é fornecida para interações, a API é desenvolvida em um sistema em camadas e a resposta é armazenável em cache pelo cliente. Há também uma restrição opcional para fornecer código sob demanda.

No entanto, com tudo isso dito - a maioria das APIs não é RESTful (de acordo com Fielding), pois não incorporam hipermídia (links de hipertexto incorporados na resposta que ajudam a navegar na API). A maioria das APIs que você descobrirá é do tipo REST, pois segue a maioria dos conceitos de REST, mas ignora essa restrição. No entanto, cada vez mais APIs estão implementando isso e está se tornando uma prática de fluxo principal.

Isso também oferece certa flexibilidade, pois as APIs orientadas à hipermídia (como Stormpath) direcionam o cliente para os URIs (ou seja, se algo mudar, em certos casos, você pode modificar o URI sem impacto negativo), onde os RRIs de RPC precisam ser estático. Com o RPC, você também precisará documentar extensivamente esses URIs diferentes e explicar como eles funcionam em relação um ao outro.

Em geral, eu diria que o REST é o caminho a percorrer, se você deseja criar uma API extensível e flexível que terá vida longa. Por esse motivo, eu diria que é o caminho a percorrer 99% do tempo.

Boa sorte, Mike

OMI, o ponto principal é a ação versus orientação de recursos. O REST é orientado a recursos e se encaixa bem nas operações CRUD e, dada a semântica conhecida, fornece alguma previsibilidade para o primeiro usuário, mas quando implementado a partir de métodos ou procedimentos o força a fornecer uma tradução artificial para o mundo centralizado em recursos. Por outro lado, o RPC se adapta perfeitamente às APIs orientadas à ação, nas quais você expõe serviços, não conjuntos de recursos compatíveis com CRUD.

Sem dúvida, o REST é mais popular, isso definitivamente adiciona alguns pontos se você deseja expor a API a terceiros.

Caso contrário (por exemplo, no caso de criar um front-end AJAX em um SPA), minha escolha é RPC. Em particular, JSON-RPC, combinado com o JSON Schema como linguagem de descrição e transportado por HTTP ou Websockets, dependendo do caso de uso.

JSON-RPC é uma especificação simples e elegante que define cargas úteis JSON de solicitação e resposta a serem usadas em RPC síncrono ou assíncrono.

O esquema JSON é uma especificação preliminar que define um formato baseado em JSON destinado a descrever dados JSON. Ao descrever suas mensagens de entrada e saída de serviço usando o JSON Schema, você pode ter uma complexidade arbitrária na estrutura da mensagem sem comprometer a usabilidade, e a integração de serviços pode ser automatizada.

A escolha do protocolo de transporte (HTTP x Websockets) depende de diferentes fatores, sendo o mais importante se você precisa de recursos HTTP (cache, revalidação, segurança, idempotência, tipo de conteúdo, multipartes, ...) ou se o aplicativo precisa trocar mensagens com altas frequências.

Até agora, é muito minha opinião pessoal sobre o assunto, mas agora algo que pode ser realmente útil para os desenvolvedores de Java que leem essas linhas, a estrutura em que venho trabalhando durante o ano passado, nascida da mesma pergunta que você está se perguntando agora :

http://rpc.brutusin.org

Você pode ver uma demonstração ao vivo aqui, mostrando o navegador do repositório interno para testes funcionais (graças ao JSON Schema) e uma série de serviços de exemplo:

http://demo.rpc.brutusin.org

Espero que ajude companheiro!

Nacho

Se seu serviço funcionar bem apenas com modelos e com o padrão GET / POST / PUT / DELETE, use REST puro.

Concordo que o HTTP foi originalmente projetado para aplicativos sem estado.

Mas para aplicativos modernos e mais complexos (!) Em tempo real (web) em que você deseja usar Websockets (o que geralmente implica estado), por que não usar os dois? O JSON-RPC sobre Websockets é muito leve, portanto, você tem os seguintes benefícios:

• Atualizações instantâneas em todos os clientes (defina sua própria chamada RPC de servidor para cliente para atualizar os modelos)
• Fácil de adicionar complexidade (tente criar um clone Etherpad apenas com REST)
• Se você fizer certo (adicione RPC apenas como um extra em tempo real), a maioria ainda poderá ser usada apenas com REST (exceto se o recurso principal for um bate-papo ou algo assim)

Como você está projetando apenas a API do lado do servidor, comece com a definição de modelos REST e depois inclua o suporte JSON-RPC conforme necessário, mantendo o número mínimo de chamadas RPC.

(e desculpe pelo uso excessivo de parênteses)

Eu sou um grande fã do REST no passado e tem muitas vantagens sobre o RPC no papel. Você pode apresentar ao cliente diferentes tipos de conteúdo, armazenamento em cache, reutilização de códigos de status HTTP, guiá-lo pela API e incorporar documentação à API, se ela não for autoexplicativa.

Mas minha experiência tem sido que, na prática, isso não se sustenta e, em vez disso, você faz muito trabalho desnecessário para acertar tudo. Além disso, os códigos de status HTTP geralmente não são mapeados exatamente para a lógica do seu domínio, e usá-los em seu contexto geralmente parece um pouco forçado. Mas a pior coisa do REST, na minha opinião, é que você gasta muito tempo para projetar seus recursos e as interações que eles permitem. E sempre que você fizer algumas adições importantes à sua API, espere encontrar uma boa solução para adicionar a nova funcionalidade e não tenha se projetado em um canto.

Isso geralmente parece uma perda de tempo para mim, porque na maioria das vezes eu já tenho uma ideia perfeitamente clara e óbvia sobre como modelar uma API como um conjunto de chamadas de procedimento remoto. E se eu fiz todo esse esforço para modelar meu problema dentro das restrições do REST, o próximo problema é como chamá-lo do cliente? Nossos programas são baseados em procedimentos de chamada, portanto, é fácil construir uma boa biblioteca de clientes RPC, criar uma boa biblioteca de clientes REST e, na maioria dos casos, você apenas mapeia de volta da API REST no servidor para um conjunto de procedimentos em seu cliente biblioteca.

Por isso, o RPC parece muito mais simples e natural para mim hoje. O que realmente sinto falta é uma estrutura consistente que facilita a gravação de serviços RPC que são autoexplicativos e interoperáveis. Portanto, criei meu próprio projeto para experimentar novas maneiras de tornar o RPC mais fácil para mim e talvez alguém o ache útil também: https://github.com/aheck/reflectrpc

De acordo com o modelo de maturidade de Richardson , a questão não é REST x RPC , mas quanto REST ?

Nesta visão, a conformidade com o padrão REST pode ser classificada em 4 níveis.

• nível 0: pense em termos de ações e parâmetros. Como o artigo explica, isso é essencialmente equivalente ao JSON-RPC (o artigo explica o XML-RPC, mas os mesmos argumentos são válidos para ambos).
• nível 1: pense em termos de recursos. Tudo o que é relevante para um recurso pertence ao mesmo URL
• nível 2: use verbos HTTP
• nível 3: HATEOAS

De acordo com o criador do padrão REST, apenas serviços de nível 3 podem ser chamados de RESTful. No entanto, essa é uma métrica de conformidade , não de qualidade. Se você apenas deseja chamar uma função remota que faz um cálculo, provavelmente não faz sentido ter links hipermídia relevantes na resposta, nem diferenciação de comportamento com base no verbo HTTP usado. Portanto, uma chamada desse tipo tende a ser mais parecida com RPC. No entanto, um nível mais baixo de conformidade não significa necessariamente um estado ou um acoplamento mais alto. Provavelmente, em vez de pensar em REST x RPC , você deve usar o máximo de REST possível, mas não mais. Não torça seu aplicativo apenas para se ajustar aos padrões de conformidade RESTful.

Por que JSON RPC:

No caso de APIs REST, precisamos definir um controlador para cada funcionalidade / método que possamos precisar. Como resultado, se tivermos 10 métodos que queremos acessíveis a um cliente, precisamos escrever 10 controladores para fazer a interface da solicitação do cliente com um método específico.

Outro fator é que, embora tenhamos controladores diferentes para cada método / funcionalidade, o cliente precisa se lembrar de usar POST ou GET. Isso complica ainda mais as coisas. Além disso, para enviar dados, é necessário definir o tipo de conteúdo da solicitação, se o POST for usado.

No caso do JSON RPC, as coisas são muito simplificadas porque a maioria dos servidores JSONRPC opera com métodos HTTP POST e o tipo de conteúdo é sempre application / json. Isso dispensa a lembrança de usar o método HTTP adequado e as configurações de conteúdo no lado do cliente.

Não é necessário criar controladores separados para diferentes métodos / funcionalidades que o servidor deseja expor para um cliente.

Por que descansar:

Você tem URLs separados para diferentes funcionalidades que o servidor deseja expor para o cliente. Como resultado, você pode incorporar esses URLs.

A maioria desses pontos é discutível e depende completamente da necessidade de uma pessoa.

Eu acho que, como sempre, depende ...

O REST tem a enorme vantagem de um amplo suporte público e isso significa muitas ferramentas e livros. Se você precisar criar uma API usada por um grande número de consumidores de diferentes organizações, esse é o caminho a seguir por apenas um motivo: é popular. Como protocolo, é claro que é uma falha total, pois existem muitas maneiras completamente diferentes de mapear um comando para uma URL / verbo / resposta.

Portanto, quando você escreve um aplicativo Web de página única que precisa conversar com um back-end, acho que o REST é muito complexo. Nessa situação, você não precisa se preocupar com a compatibilidade a longo prazo, pois o aplicativo e a API podem evoluir juntos.

Uma vez, comecei com o REST para um aplicativo Web de página única, mas os comandos detalhados entre o aplicativo Web e o servidor rapidamente me deixaram louco. Devo codificá-lo como um parâmetro de caminho? No corpo? Um parâmetro de consulta? Um cabeçalho? Após o design da URL / Verbo / Resposta, tive que codificar essa bagunça em Javascript, o decodificador em Java e depois chamar o método real. Embora existam muitas ferramentas para isso, é realmente complicado não obter semântica HTTP no código de domínio, o que é realmente uma prática ruim. (Coesão)

Tente criar um arquivo Swagger / OpenAPI para um site de média complexidade e compare-o a uma única interface Java que descreve os procedimentos remotos nesse arquivo. O aumento da complexidade é impressionante.

Portanto, mudei de REST para JSON-RPC para o webapp de página única. a Desenvolvi uma pequena biblioteca que codificava uma interface Java no servidor e a enviava para o navegador. No navegador, isso criou um proxy para o código do aplicativo que retornou uma promessa para cada função.

Novamente, o REST tem seu lugar apenas por ser famoso e, portanto, bem suportado. Também é importante reconhecer a filosofia dos recursos apátridas subjacentes e o modelo hierárquico. No entanto, esses princípios podem ser facilmente utilizados em um modelo de RPC. O JSON RPC funciona sobre HTTP, portanto, possui as mesmas vantagens do REST nessa área. A diferença é que, quando você inevitavelmente se depara com essas funções que não mapeiam bem esses princípios, não é obrigado a fazer muito trabalho desnecessário.

O REST está fortemente associado ao HTTP; portanto, se você expor sua API apenas por HTTP, o REST é mais apropriado para a maioria das situações (mas não todas). No entanto, se você precisar expor sua API a outros transportes, como mensagens ou soquetes da Web, o REST não será aplicável.

Seria melhor escolher JSON-RPC entre REST e JSON-RPC para desenvolver uma API para um aplicativo da Web mais fácil de entender. O JSON-RPC é preferido porque seu mapeamento para chamadas e comunicações de método pode ser facilmente entendido.

A escolha da abordagem mais adequada depende das restrições ou do objetivo principal. Por exemplo, na medida em que o desempenho é uma característica importante, é recomendável usar o JSON-RPC (por exemplo, computação de alto desempenho). No entanto, se o objetivo principal é ser agnóstico, a fim de oferecer uma interface genérica a ser inferida por outros, é aconselhável optar pelo REST. Se você precisa atingir os dois objetivos, é recomendável incluir os dois protocolos.

O fato que realmente separa o REST do JSON-RPC é que ele rastreia uma série de restrições cuidadosamente pensadas - confirmando a flexibilidade da arquitetura. As restrições são tomadas para garantir que o cliente e o servidor possam crescer independentemente um do outro (as alterações podem ser feitas sem atrapalhar a aplicação do cliente), as chamadas são sem estado (o estado é considerado hipermídia), um uniforme interface é oferecida para interações, a API é avançada em um sistema em camadas (Hall, 2010). O JSON-RPC é rápido e fácil de consumir, no entanto, como os recursos mencionados e os parâmetros são fortemente acoplados, é provável que dependa de verbos (api / addUser, api / deleteUser) usando GET / POST, enquanto o REST fornece recursos de baixo acoplamento (api / usuários) em um HTTP. A API REST depende de vários métodos HTTP, como GET, PUT, POST, DELETE, PATCH.

JSON (denotado como JavaScript Object Notation), sendo um formato leve de intercâmbio de dados, é fácil para os humanos lerem e escreverem. É fácil para máquinas analisar e gerar. JSON é um formato de texto que é totalmente independente da linguagem, mas pratica convenções que são conhecidas pelos programadores da família de linguagens, consistindo em C #, C, C ++, Java, Perl, JavaScript, Python e várias outras. Essas propriedades tornam o JSON uma linguagem perfeita de intercâmbio de dados e uma melhor opção para se optar.

Pergunta errada: impõe um maniqueísmo que não existe!

Você pode usar JSON-RPC com "menos verbo" (sem método ) e preservar a padronização mínima necessária para identificação, parâmetros, códigos de erro e mensagens de aviso . O padrão JSON-RPC não diz "você não pode ser REST", apenas diz como compactar informações básicas.

"REST JSON-RPC" existe ! é REST com "melhores práticas", para empacotamento mínimo de informações, com contratos simples e sólidos.

Exemplo

( desta resposta e contexto didático)

Ao lidar com o REST, geralmente ajuda começar pensando em termos de recursos. Nesse caso, o recurso não é apenas "conta bancária", mas é uma transação dessa conta bancária ... Mas o JSON-RPC não obriga ao parâmetro "method", todos são codificados por "path" do nó de extremidade.

• Depósito REST com POST /Bank/Account/John/Transactionsolicitação JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  A resposta JSON pode ser algo como{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• REST Retirar com POST /Bank/Account/John/Transaction... semelhante.

• ... GET /Bank/Account/John/Transaction/12345@13... Isso pode retornar um registro JSON dessa transação exata (por exemplo, seus usuários geralmente desejam um registro de débitos e créditos em suas contas). Algo como {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. A convenção sobre a solicitação GET (REST) ​​pode incluir a codificação do ID por "@id", portanto, não é necessário enviar nenhum JSON, mas ainda usando JSON-RPC no pacote de resposta.

Se você solicitar recursos, a API RESTful será melhor por design. Se você solicitar alguns dados complicados com muitos parâmetros e métodos complicados que não sejam simples CRUD, o RPC é o caminho certo a seguir.

Eu uso o vdata para o protocolo RPC: http://vdata.dekuan.org/

1, PHP e JavaScript estão bem. 2, a chamada de compartilhamento de recursos de origem cruzada (CORS) ainda está correta.