não está orientada para o recurso realmente orientada a objetos?

StackOverflow https://stackoverflow.com/questions/152871

  •  02-07-2019
  •  | 
  •  

Pergunta

Quando você pensa sobre isso, não o paradigma RESTO de ser ferver orientada a recurso resume a ser orientada a objetos (com a funcionalidade restrita, aproveitando HTTP, tanto quanto possível)?

Eu não estou dizendo necessariamente é uma coisa ruim, mas sim que se forem essencialmente o mesmo muito semelhante, em seguida, torna-se muito mais fácil de entender REST e as implicações que tal uma arquitetura implica.

Update: Aqui estão detalhes mais específicos:

  1. recursos restantes são equivalente a classes públicas. aulas particulares / recursos simplesmente não estão expostos.
    2. estado
  2. Resource é equivalente a métodos públicos da classe ou campos. Privado métodos / campos / Estado simplesmente não está exposta (isto não significa que não está lá).
  3. Embora seja certamente verdade que o descanso não retém estado específico do cliente através de solicitações, ele não reter estado do recurso em todos os clientes. Recursos Have estado, da mesma forma que as classes têm estado.
  4. recursos REST são são globalmente identificada exclusivamente por um URI da mesma maneira que os objetos do servidor são globalmente identificado exclusivamente por seu endereço de banco de dados, nome da tabela e chave primária. Concedido há (ainda) não é um URI para representar isso, mas você pode facilmente construir um.
Foi útil?

Solução

REST é semelhante ao OO na medida em que tanto o modelo do mundo como entidades que aceitam mensagens (ou seja, métodos), mas para além de que eles são diferentes.

orientação objecto enfatiza encapsulamento de estado e opacidade , utilizando como muitos métodos diferentes necessários para operar sobre o estado. REST é sobre a transferência de (representação) Estado e transparência . O número de métodos usados ??na RESTO é limitado e uniforme em todas recursos. O mais próximo a isso em OOP é o método ToString() que é muito mais ou menos equivalente a um HTTP GET.

A orientação a objetos é stateful - você se referir a um objeto e pode chamar métodos nele, mantendo estado dentro de uma sessão onde o objeto ainda está no escopo. REST é apátrida -. Tudo o que você quer fazer com um recurso é especificado em uma única mensagem e tudo que você sempre precisa saber sobre essa mensagem é enviada de volta em uma única resposta

Na orientação a objetos, não existe o conceito de identidade de objeto universal - Objectos quer obter a identidade de seu endereço de memória a qualquer momento particular, um específico do quadro UUID, ou a partir de um banco de dados chave. No estudo REST todos os recursos são identificados com um URI e não precisa ser instanciado ou eliminados - eles sempre existir na nuvem a menos que os responde servidor com um 404 Not Found ou 410 Longe , em caso whch você sabe que não há recurso com esse URI.

RESTO tem garantias de segurança (por exemplo, uma mensagem GET não vai mudar de estado) e idempotência (por exemplo, um pedido PUT enviado várias vezes tem mesmo efeito que apenas um tempo). Embora algumas diretrizes para determinadas tecnologias orientadas a objetos têm algo a dizer sobre a forma como certas construções afetar o estado, não há realmente nada sobre orientação a objetos que diz alguma coisa sobre segurança e idempotência.

Outras dicas

Eu acho que há uma diferença entre dizer um conceito pode ser expresso em termos de objetos e dizendo o conceito é o mesma como orientação a objetos.

ofertas OO uma maneira de descrever conceitos REST. Isso não significa em si RESTO implementa OO.

Você tem razão. Dan Connolly escreveu um artigo sobre isso em 1997. a Fielding tese também fala sobre isso.

Objetos estado e função pacote juntos. Resource-orientação é sobre modelar explicitamente estado (dados), limitando função para verbos predefinidos com semântica universais (No caso de HTTP, GET / PUT / POST / DELETE), e deixando o resto do processamento para o cliente.

Não há equivalente para esses conceitos no mundo da orientação a objetos.

Apenas se os objetos são DTOs ( Transferência Data Objects ) - desde que você não pode realmente tem um comportamento diferente de persistência.

Sim, sua paralela à orientação a objetos está correto.

A coisa é, a maioria dos webservices (REST, RESTful, SOAP, ..) pode passar informações na forma de objetos, de modo que não é o que o torna diferente. SABÃO tende a conduzir a menos serviços com mais métodos. Repouso tende a levar a mais serviços (1 por tipo de recurso) com algumas chamadas de cada um.

Sim, REST é sobre transferência de objetos. Mas não é todo o objeto; apenas o estado atual do objeto. A suposição implícita é que as definições de classes de ambos os lados do resto são potencialmente semelhante; caso contrário, o estado do objeto foi coagido a algum objeto novo.

RESTO só se preocupa com 4 eventos na vida de um objeto, criar (POST), recuperar (GET), update (PUT) e excluir. Eles são eventos significativos, mas há apenas estes quatro.

Um objeto pode participar em muitas outros eventos com muitos outros objetos. Tudo o resto deste comportamento é completamente fora da abordagem REST.

Há uma relação estreita - Resto move objetos -. Mas dizendo que eles são o mesmo reduz seus objetos para coleções passivos de bits com nenhum método

resto não é apenas sobre os objetos, a sua também sobre as propriedades :: uma solicitação POST para / usuários / john / phone_number com um novo número de telefone não está adicionando um novo objeto, a sua localização numa propriedade do objeto usuário 'john'

Este é nem mesmo o todo estado do objeto, mas apenas uma mudança para uma pequena parte do estado.

Não é certamente uma. 1: jogo 1

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top