Diferenças de serviço da Web entre REST e RPC

Tenho um serviço da web que aceita parâmetros JSON e tenho URLs específicos para métodos, por exemplo:

http://IP:PORT/API/getAllData?p={JSON}

Definitivamente, não é REST, pois não é sem estado. Leva os cookies em consideração e tem sua própria sessão.

É RPC? Qual é a diferença entre RPC e REST?

Você não pode fazer uma separação clara entre REST ou RPC apenas olhando o que você postou.

Uma restrição do REST é que ele precisa ser sem estado. Se você tem uma sessão, então você tem estado, então não pode chamar seu serviço de RESTful.

O fato de você ter uma ação em seu URL (ou seja getAllData) é uma indicação para RPC. No REST, você troca representações e a operação que você executa é ditada pelos verbos HTTP. Além disso, em REST, a negociação de conteúdo não é realizada com um ?p={JSON}parâmetro.

Não sei se o seu serviço é RPC, mas não é RESTful. Você pode aprender sobre a diferença online. Aqui está um artigo para você começar: Desmascarando os mitos de RPC e REST . Você sabe melhor o que está dentro do seu serviço, então compare suas funções com o que é RPC e tire suas próprias conclusões.

Considere o seguinte exemplo de APIs HTTP que modelam os pedidos feitos em um restaurante.

• A API RPC pensa em termos de "verbos", expondo a funcionalidade do restaurante como chamadas de função que aceitam parâmetros e invoca essas funções por meio do verbo HTTP que parece mais apropriado - um 'get' para uma consulta e assim por diante, mas o nome do verbo é puramente incidental e não tem nenhuma relação real com a funcionalidade real, já que você está chamando um URL diferente a cada vez . Os códigos de retorno são codificados manualmente e fazem parte do contrato de serviço.
• A API REST , em contraste, modela as várias entidades dentro do domínio do problema como recursos e usa verbos HTTP para representar transações em relação a esses recursos - POST para criar, PUT para atualizar e GET para ler. Todos esses verbos, invocados no mesmo URL , fornecem funcionalidades diferentes. Códigos de retorno HTTP comuns são usados ​​para transmitir o status das solicitações.

Colocar uma ordem:

• RPC: http: // MyRestaurant: 8080 / Orders / PlaceOrder (POST: {objeto Tacos})
• REST: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (POST: {objeto Tacos})

Recuperando um pedido:

• RPC: http: // MyRestaurant: 8080 / Orders / GetOrder? OrderNumber = asdf (GET)
• REST: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (GET)

Atualizando um pedido:

• RPC: http: // MyRestaurant: 8080 / Orders / UpdateOrder (PUT: {Pineapple Tacos object})
• REST: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (PUT: {Pineapple Tacos object})

Exemplo retirado de sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc

Como já foi dito, uma diferença importante é que REST é centrado no substantivo e RPC é centrado no verbo. Eu só queria incluir esta tabela clara de exemplos que demonstram que:

--------------------------- + ---------------------- --------------- + --------------------------
  Operação                  | RPC (operação)                      | REST (recurso)
--------------------------- + ---------------------- --------------- + --------------------------
 Cadastre-se | POST / inscrição | POST / pessoas           
--------------------------- + ---------------------- --------------- + --------------------------
 Renuncie | POST / renúncia | APAGAR / pessoas / 1234    
--------------------------- + ---------------------- --------------- + --------------------------
 Ler pessoa | GET / readPerson? Personid = 1234 | GET / pessoas / 1234       
--------------------------- + ---------------------- --------------- + --------------------------
 Ler a lista de itens da pessoa | GET / readUsersItemsList? Userid = 1234 | GET / pessoas / 1234 / itens
--------------------------- + ---------------------- --------------- + --------------------------
 Adicionar item à lista de pessoas | POST / addItemToUsersItemsList | POST / pessoas / 1234 / itens
--------------------------- + ---------------------- --------------- + --------------------------
 Atualizar item | POST / modifyItem | COLOCAR / itens / 456          
--------------------------- + ---------------------- --------------- + --------------------------
 Excluir item | POST / removeItem? ItemId = 456 | APAGAR / itens / 456       
--------------------------- + ---------------------- --------------- + --------------------------

Notas

• Como mostra a tabela, REST tende a usar parâmetros de caminho de URL para identificar recursos específicos
  (por exemplo GET /persons/1234), enquanto RPC tende a usar parâmetros de consulta para entradas de função
  (por exemplo GET /readPerson?personid=1234).
• Não é mostrado na tabela como uma API REST trataria a filtragem, que normalmente envolveria parâmetros de consulta (por exemplo GET /persons?height=tall).
• Também não é mostrado como com qualquer sistema, quando você cria / atualiza operações, dados adicionais são provavelmente passados ​​através do corpo da mensagem (por exemplo, quando você faz POST /signupou POST /personsinclui dados que descrevem a nova pessoa).
• Obviamente, nada disso está definido em pedra, mas dá uma ideia do que você provavelmente encontrará e como você pode querer organizar sua própria API para consistência. Para uma discussão mais aprofundada do design de URL REST, consulte esta pergunta .

É RPC usando http . Uma implementação correta de REST deve ser diferente de RPC. Ter uma lógica para processar dados, como um método / função, é RPC. getAllData () é um método inteligente. REST não pode ter inteligência, deve ser dados de despejo que podem ser consultados por uma inteligência externa .

A maioria das implementações que tenho visto atualmente são RPC, mas muitos os chamam por engano de REST. REST com HTTP é o salvador e SOAP com XML, o vilão. Então sua confusão é justificada e você está certo, não é REST.

O protocolo Http não faz uma implementação de REST. Tanto REST (GET, POST, PUT, PATCH, DELETE) e RPC (GET + POST) podem ser desenvolvidos através de HTTP (ex: através de um projeto de API web no Visual Studio).

Tudo bem, mas o que é REST então? O modelo de maturidade de Richardson é fornecido abaixo (resumido). Apenas o nível 3 é RESTful.

• Nível 0: Http POST
• Nível 1: cada recurso / entidade tem um URI (mas ainda apenas POST)
• Nível 2: POST e GET podem ser usados
• Nível 3 (RESTful): Usa HATEOAS (links de hipermídia) ou, em outras palavras, links de autoexploração

por exemplo: nível 3 (HATEOAS):

1. O link indica que este objeto pode ser atualizado desta forma e adicionado desta forma.

2. O link indica que este objeto só pode ser lido e é assim que o fazemos.

   Claramente, o envio de dados não é suficiente para se tornar REST, mas como consultar os dados, também deve ser mencionado. Mas, novamente, por que as 4 etapas? Por que não pode ser apenas a Etapa 4 e chamá-la de REST? Richardson apenas nos deu uma abordagem passo a passo para chegar lá, só isso.

Você construiu sites que podem ser usados ​​por humanos. Mas você também pode construir sites que podem ser usados ​​por máquinas? É aí que está o futuro, e RESTful Web Services mostra como fazer isso.

• Este livro RESTful Web Services ajuda
• Uma leitura muito interessante RPC vs REST

PS: REST é muito popular, então é o teste automatizado, mas quando se trata de exemplos do mundo real ... bem ...

REST é melhor descrito para trabalhar com os recursos, enquanto RPC é mais sobre as ações.

REST significa Transferência de Estado Representacional. É uma maneira simples de organizar as interações entre sistemas independentes. Os aplicativos RESTful normalmente usam solicitações HTTP para postar dados (criar e / ou atualizar), ler dados (por exemplo, fazer consultas) e excluir dados. Portanto, o REST pode usar HTTP para todas as quatro operações CRUD (Criar / Ler / Atualizar / Excluir).

O RPC é basicamente usado para se comunicar entre os diferentes módulos para atender às solicitações do usuário. por exemplo, em uma pilha aberta, como a nova, o aspecto e o nêutron trabalham juntos ao inicializar uma máquina virtual.

Eu argumentaria assim:

Minha entidade possui / possui os dados? Então RPC: aqui está uma cópia de alguns dos meus dados, manipule a cópia dos dados que envio para você e devolva-me uma cópia do seu resultado.

A entidade chamada possui / possui os dados? Em seguida, REST: (1) mostre-me uma cópia de alguns de seus dados ou (2) manipule alguns de seus dados.

Em última análise, trata-se de qual "lado" da ação possui / mantém os dados. E sim, você pode usar a verborragia REST para se comunicar com um sistema baseado em RPC, mas ainda estará realizando atividades RPC ao fazer isso.

Exemplo 1: Eu tenho um objeto que está se comunicando com um armazenamento de banco de dados relacional (ou qualquer outro tipo de armazenamento de dados) por meio de um DAO. Faz sentido usar o estilo REST para essa interação entre meu objeto e o objeto de acesso a dados que pode existir como uma API. Minha entidade não possui / mantém os dados, o banco de dados relacional (ou armazenamento de dados não relacional) sim.

Exemplo 2: eu preciso fazer muita matemática complexa. Não quero carregar um monte de métodos matemáticos em meu objeto, só quero passar alguns valores para outra pessoa que pode fazer todos os tipos de matemática e obter um resultado. Então, o estilo RPC faz sentido, porque o objeto / entidade matemática irá expor ao meu objeto um monte de operações. Observe que todos esses métodos podem ser expostos como APIs individuais e posso chamar qualquer um deles com GET. Posso até afirmar que é RESTful porque estou chamando via HTTP GET, mas, na verdade, é RPC. Minha entidade possui / mantém os dados, a entidade remota está apenas realizando manipulações nas cópias dos dados que enviei para ela.

No HTTP, ambos acabam sendo apenas HttpRequestobjetos e ambos esperam um HttpResponseobjeto de volta. Acho que podemos continuar codificando com essa descrição e nos preocuparmos com outra coisa.

Existem várias respostas boas aqui. Eu ainda recomendaria este blog do google, pois ele faz um ótimo trabalho ao discutir as diferenças entre RPC e REST e captura algo que não li em nenhuma das respostas aqui.

Eu citaria um parágrafo do mesmo link que se destacou para mim:

O próprio REST é uma descrição dos princípios de design que sustentam o HTTP e a rede mundial. Mas, como HTTP é a única API REST comercialmente importante, podemos evitar a discussão de REST e nos concentrar apenas em HTTP. Essa substituição é útil porque há muita confusão e variabilidade no que as pessoas pensam que REST significa no contexto de APIs, mas há muito mais clareza e concordância sobre o que é o próprio HTTP. O modelo HTTP é o inverso perfeito do modelo RPC - no modelo RPC, as unidades endereçáveis ​​são procedimentos, e as entidades do domínio do problema estão ocultas atrás dos procedimentos. No modelo HTTP, as unidades endereçáveis ​​são as próprias entidades e os comportamentos do sistema ficam ocultos por trás das entidades como efeitos colaterais de sua criação, atualização ou exclusão.

É assim que eu os entendo e os uso em diferentes casos de uso:

Exemplo: gerenciamento de restaurante

caso de uso para REST : gerenciamento de pedidos

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

Para gerenciamento de recursos, REST é limpo. Um ponto final com ações predefinidas. Pode ser visto uma forma de expor um banco de dados (Sql ou NoSql) ou instâncias de classe para o mundo.

Exemplo de implementação:

class order:
    on_get(self, req, resp): doThis.
    on_patch(self, req, resp): doThat.

Exemplo de framework: Falcon para python.

caso de uso para RPC : gerenciamento de operação

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

Para trabalhos analíticos, operacionais, não responsivos, não representativos e baseados em ações, o RPC funciona melhor e é muito natural pensar funcional.

Exemplo de implementação:

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.

@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

Exemplo de estrutura: Flask para python