¿No está orientado a los recursos realmente orientado a objetos?

Question

Cuando lo piensas, ¿el paradigma de REST de estar orientado a los recursos se reduce a orientarse a objetos (con funcionalidad restringida, aprovechando HTTP tanto como sea posible)?

No necesariamente estoy diciendo que sea algo malo, sino que si son esencialmente lo mismo muy similares, se vuelve mucho más fácil entender el REST y las implicaciones que conlleva dicha arquitectura.

Actualización: Aquí hay detalles más específicos:

1. Los recursos REST son equivalentes a las clases públicas. Las clases / recursos privados simplemente no están expuestos.
2. El estado del recurso es equivalente a los métodos o campos públicos de clase. Los métodos / campos / estado privados simplemente no están expuestos (esto no significa que no estén ahí).
3. Si bien es cierto que REST no retiene el estado específico del cliente en todas las solicitudes, sí retiene el estado de los recursos en todos los clientes. Los recursos tienen estado, del mismo modo que las clases tienen estado.
4. Los recursos REST se identifican globalmente de forma única mediante un URI de la misma manera que los objetos del servidor se identifican globalmente de forma única por la dirección de su base de datos, el nombre de la tabla y la clave principal. Por supuesto, no hay (todavía) un URI para representar esto, pero puede construir uno fácilmente.

Answer 1

REST es similar a OO en que ambos modelan el mundo como entidades que aceptan mensajes (es decir, métodos) pero más allá de eso son diferentes.

La orientación a objetos enfatiza la encapsulación de estado y la opacidad , utilizando tantos métodos diferentes como sea necesario para operar en el estado. REST trata sobre la transferencia de (representación de) estado y transparencia . El número de métodos utilizados en REST está restringido y es uniforme en todos los recursos de todos . Lo más cercano a eso en OOP es el método ToString () que es aproximadamente equivalente a un HTTP GET.

La orientación del objeto es con estado : se refiere a un objeto y puede invocar métodos mientras se mantiene dentro de una sesión en la que el objeto todavía está dentro del alcance. REST es sin estado : todo lo que desea hacer con un recurso se especifica en un solo mensaje y todo lo que necesita saber sobre ese mensaje se envía en una sola respuesta.

En la orientación a objetos, no hay un concepto de identidad de objeto universal : los objetos obtienen la identidad de su dirección de memoria en un momento determinado, un UUID específico del marco o una clave de base de datos. En REST todos los recursos se identifican con un URI y no es necesario crear una instancia o eliminarlos; siempre existen en la nube a menos que el servidor responda con un 404 No encontrado o 410 Gone , en caso de que sepa que no hay recursos con ese URI.

REST tiene garantías de seguridad (por ejemplo, un mensaje GET no cambiará de estado) y idempotencia (por ejemplo, una solicitud PUT enviada varias veces tiene el mismo efecto que solo una vez). Aunque algunas pautas para tecnologías orientadas a objetos particulares tienen algo que decir acerca de cómo ciertas construcciones afectan el estado, realmente no hay nada acerca de la orientación a objetos que diga nada sobre seguridad e idempotencia.

Answer 2

Creo que hay una diferencia entre decir que un concepto puede expresarse en términos de objetos y decir que el concepto es el mismo como orientación al objeto.

OO ofrece una manera de describir los conceptos REST. Eso no significa que REST implemente OO.

Answer 3

Tienes razón. Dan Connolly escribió un artículo sobre esto en 1997. La tesis de Fielding también habla de ello.

Answer 4

Los objetos agrupan el estado y funcionan juntos. La orientación de los recursos consiste en modelar explícitamente el estado (datos), limitar la función a verbos predefinidos con semántica universal (en el caso de HTTP, GET / PUT / POST / DELETE) y dejar el resto del procesamiento al cliente.

No hay equivalente para estos conceptos en el mundo de orientación a objetos.

Answer 5

Solo si sus objetos son DTO ( Objetos de transferencia de datos ) - ya que no puede realmente tienen un comportamiento diferente a la persistencia.

Answer 6

Sí, tu paralelo con la orientación a objetos es correcto.

La cuestión es que la mayoría de los servicios web (REST, RESTful, SOAP, ...) pueden pasar información en forma de objetos, por lo que no es lo que lo hace diferente. SOAP tiende a conducir a menos servicios con más métodos. REST tiende a generar más servicios (1 por tipo de recurso) con unas pocas llamadas cada una.

Answer 7

Sí, REST es sobre la transferencia de objetos. Pero no es todo el objeto; sólo el estado actual del objeto. El supuesto implícito es que las definiciones de clase en ambos lados de la REST son potencialmente similares; de lo contrario, el estado del objeto se ha convertido en un nuevo objeto.

REST solo se ocupa de 4 eventos en la vida de un objeto, crear (POST), recuperar (GET), actualizar (PUT) y eliminar. Son eventos significativos, pero solo hay estos cuatro.

Un objeto puede participar en muchos otros eventos con muchos otros objetos. Todo el resto de este comportamiento está completamente fuera del enfoque REST.

Hay una relación cercana: REST mueve objetos, pero decir que son lo mismo reduce tus objetos a colecciones pasivas de bits sin métodos.

Answer 8

REST no se trata solo de objetos, sino también de propiedades: una solicitud posterior a / users / john / phone_number con un nuevo número de teléfono no agrega un nuevo objeto, es una propiedad del objeto de usuario 'john'

Esto no es ni siquiera el estado completo del objeto, sino solo un cambio en una pequeña parte del estado.

Ciertamente no es una coincidencia 1: 1.