years universidad notables millennials millennial egresados davis carreras california agriculture rest api terminology

rest - universidad - uc davis ranking



¿Qué son los recursos REST? (11)

¿Qué es un recurso?

Un recurso es cualquier cosa que sea lo suficientemente importante como para ser referenciado como una cosa en sí misma. Si sus usuarios pueden "querer crear un enlace de hipertexto hacia él, realizar o refutar afirmaciones al respecto, recuperar o almacenar en caché una representación de él, incluir todo o parte de él por referencia en otra representación, anotarlo o realizar otras operaciones en él ", Entonces deberías convertirlo en un recurso.

Por lo general, un recurso es algo que puede almacenarse en una computadora y representarse como una secuencia de bits: un documento, una fila en una base de datos o el resultado de ejecutar un algoritmo. Un recurso puede ser un objeto físico como una manzana, o un concepto abstracto como el coraje, pero (como veremos más adelante) las representaciones de tales recursos son necesariamente decepcionantes. Aquí hay algunos recursos posibles:

  • Versión 1.0.3 del lanzamiento del software
  • La última versión de la versión del software
  • La primera entrada del blog para el 24 de octubre de 2006
  • Una hoja de ruta de Little Rock, Arkansas
  • Alguna información sobre medusas
  • Un directorio de recursos relacionados con las medusas
  • El siguiente número primo después de 1024
  • Los siguientes cinco números primos después de 1024
  • Los números de ventas para Q42004
  • La relación entre dos conocidos, Alice y Bob
  • Una lista de los errores abiertos en la base de datos de errores

El texto es del libro de O''Reilly " RESTful Web Services ".

¿Qué son los recursos REST y cómo se relacionan con los nombres de los recursos y las representaciones de recursos?

Leí algunos artículos sobre el tema, pero eran demasiado abstractos y me dejaron más confundido de lo que estaba antes.

¿La siguiente URL es un recurso? Si lo es, ¿cuál es el nombre de ese recurso y cuál es su representación?

http://api.example.com/users.json?length=2&offset=5

La respuesta GET de la URL debe verse más o menos así:

[ { id: 6, name: "John" }, { id: 7, name: "Jane" } ]

¿Qué son los recursos REST y cómo se relacionan con los nombres de los recursos y las representaciones de recursos?

REST no significa mucho más que los verbos HTTP (GET, POST, PUT, DELETE, etc.) correctamente.

¿La siguiente URL es un recurso?

Todas las URL son cadenas que indican a las computadoras dónde se puede ubicar un recurso. (De ahí el nombre: Localizador uniforme de recursos ).

DESCANSO

Este estilo arquitectónico se definió en el capítulo 5 de la disertación de Roy T. Fielding.

REST se trata de la manipulación del estado de los recursos a través de sus representaciones en la parte superior de la comunicación sin estado entre el cliente y el servidor. Es un estilo arquitectónico independiente del protocolo pero, en la práctica, se implementa comúnmente en la parte superior del protocolo HTTP.

Recursos

El recurso en sí es una abstracción y, en palabras del autor, un recurso puede ser cualquier información que pueda nombrarse . Las entidades de dominio de una aplicación (por ejemplo, una persona, un usuario, una factura, una colección de facturas, etc.) pueden ser recursos. Vea la siguiente cita de la disertación de Fielding:

5.2.1.1 Recursos e identificadores de recursos

La abstracción clave de la información en REST es un recurso . Cualquier información que pueda nombrarse puede ser un recurso: un documento o imagen, un servicio temporal (por ejemplo, "el clima actual en Los Ángeles"), una colección de otros recursos, un objeto no virtual (por ejemplo, una persona), etc. . En otras palabras, cualquier concepto que pueda ser el objetivo de la referencia de hipertexto de un autor debe ajustarse a la definición de un recurso. Un recurso es un mapeo conceptual para un conjunto de entidades, no la entidad que corresponde al mapeo en un punto particular en el tiempo.

Más precisamente, un recurso R es una función de pertenencia que varía temporalmente M R (t) , que para el tiempo t mapea a un conjunto de entidades, o valores, que son equivalentes. Los valores en el conjunto pueden ser representaciones de recursos y / o identificadores de recursos . [...]

Representaciones de recursos

Un documento JSON es una representación de recursos que le permite representar el estado de un recurso. Un servidor puede proporcionar representaciones diferentes para el mismo recurso. Por ejemplo, usando documentos XML y JSON. Un cliente puede usar la negociación de contenido para solicitar diferentes representaciones del mismo recurso.

Citando la disertación de Fielding:

5.2.1.2 Representaciones

Los componentes REST realizan acciones en un recurso mediante el uso de una representación para capturar el estado actual o previsto de ese recurso y la transferencia de esa representación entre los componentes. Una representación es una secuencia de bytes, más metadatos de representación para describir esos bytes. Otros nombres comúnmente utilizados pero menos precisos para una representación incluyen: documento, archivo y entidad de mensaje HTTP, instancia o variante.

Una representación consiste en datos, metadatos que describen los datos y, en ocasiones, metadatos para describir los metadatos (generalmente con el propósito de verificar la integridad del mensaje). Los metadatos se presentan en forma de pares nombre-valor, donde el nombre corresponde a un estándar que define la estructura y la semántica del valor. Los mensajes de respuesta pueden incluir metadatos de representación y metadatos de recursos: información sobre el recurso que no es específica de la representación suministrada. [...]

En HTTP, los encabezados de solicitud y respuesta se pueden usar para intercambiar metadatos sobre la representación.

Identificadores de recursos

Una URL un identificador de recursos que identifica / localiza un recurso en el servidor.

Esta answer también puede ser perspicaz.

¿Qué es REST?

REST es un estilo de arquitectura que representa la transferencia de estado representativo (RE) (S) (T).

¿Qué es el recurso REST?

Recurso de reposo son los datos sobre los que queremos realizar operaciones. Por lo tanto, estos datos pueden estar presentes en la base de datos como registro (s) de tabla (s) o de cualquier otra forma. Este registro tiene un identificador único con el que se puede identificar como identificación para el empleado.

Ahora cuando estos datos son solicitados por url único como http://www.example.com/employees/123,so , entonces los datos o registros que están presentes en la base de datos se convertirán a JSON / XML / formato de texto sin formato por el Servicio de Rest ser enviado al consumidor

Entonces, básicamente, lo que está sucediendo aquí es TRANSFERENCIA DE ESTADO REPRESENTATIVO, de manera que el estado de los datos presentes en la base de datos se transfiere a otro formato que puede ser JSON / XML o texto sin formato.

Entonces, en este caso, 1 empleado representa 1 recurso al que se puede acceder mediante una URL única, como http://www.example.com/employees/123

En caso de que deseemos obtener una lista de todos los recursos (empleados), haremos: http://www.example.com/employees

Espero que esto ayude

Conceptualmente, puede pensar en un recurso como todo lo que es accesible en la web usando una URL. Si se atiene a esta regla, http://api.example.com/users.json?length=2&offset=5 se puede considerar un recurso

La URL nunca es un recurso o su nombre o su representación.

La URL solo indica dónde se encuentra el recurso y puede invocar GET, POST, PUT, DELETE, etc. en esta URL para invocar el recurso.

Los datos respondidos son los recursos mientras que la forma de los datos es su representación.

Digamos que su URL con los parámetros GET dados puede generar un recurso JSON: esta es la representación JSON de este recurso. Si bien con otra bandera en el GET podría responder con los mismos datos en XML, esa será otra representación del mismo recurso.

EDITAR: debido a los comentarios al OP y a mi respuesta, estoy agregando otras explicaciones.

También el nombre del recurso se considera el ''nombre del script'', por ejemplo, en este caso es users.json mientras que este nombre de recurso describe por sí mismo la representación del recurso en sí: cuando se llama a este recurso, esperamos que el recurso esté en JSON, mientras se llama por ejemplo, users.xml , esperaríamos los datos en XML.

  1. Cuando cambio el parámetro de offset en GET, la respuesta contiene un conjunto de datos diferente: ¿es un recurso nuevo o su representación?
  2. Cuando defino qué columnas se devuelven en respuesta en GET, ¿es un recurso diferente o una representación diferente, o?
  1. Bueno, aquí el problema y la respuesta son claros: aún llamamos a la misma URL, las respuestas del servidor con los datos en la misma forma (aún es JSON), los datos aún contienen información sobre los usuarios, solo la información ha cambiado debido a la nuevo parámetro de compensación. Por lo tanto, es obvio que sigue siendo el mismo recurso con la misma representación y el mismo nombre de recurso que antes .
  2. El segundo problema podría ser un poco confuso. Aunque estamos llamando al mismo recurso, aunque el recurso contiene los mismos datos (solo con un conjunto de columnas predefinido) y aunque los datos están en la misma representación, podría parecernos un recurso diferente. Pero debido a los puntos en el párrafo anterior, no es ni el recurso diferente ni la representación diferente. Aunque el conjunto de datos contiene menos información, el lado solicitante (que filtra este conjunto de datos) debería considerar esto y comportarse como corresponde. Entonces otra vez: es el mismo recurso con el mismo nombre de recurso y la misma representación de recursos .

La razón por la cual los artículos sobre recursos REST son abstractos se debe a que el concepto de recurso REST es abstracto. Básicamente es "cualquier cosa a la que acceda la URL que proporciona". Entonces, en su ejemplo, el recurso sería la lista de dos usuarios comenzando en el desplazamiento 5 en una lista más grande. Tenga en cuenta que la forma en que se implementa el recurso es un detalle que no le importa a menos que sea usted quien escriba la implementación.

¿La siguiente URL es un recurso?

La URL no es un recurso, es una etiqueta que identifica el recurso, es, si lo desea, el nombre del recurso.

El JSON es una representación del recurso.

REST significa REPRESENTACION DE TRANSFERENCIA DE ESTADO. Es un método para transferir información variable de una ubicación a otra. Un método común para hacer esto es usar JSON, una forma de formatear sus variables para que puedan ser transferidas sin pérdida de información.

PHP, por ejemplo, ha incorporado compatibilidad con JSON. Pasar una matriz de PHP a json_encode($array) dará como resultado una cadena en el formato que ha publicado (que, por cierto, es de hecho un recurso REST, porque le da variables e información).

En PHP, la matriz que publicaste se convertiría en:

Array ( [0]=>Array ( [''id'']=>6; [''name'']=>''John''; ) [1]=>Array ( [''id'']=>7; [''name'']=>''Jane''; ) )

Representational State Transfer (REST) ​​es un estilo de arquitectura de software para sistemas distribuidos como la World Wide Web. Las arquitecturas de estilo REST consisten en clientes y servidores. Los clientes inician solicitudes a los servidores; los servidores procesan las solicitudes y devuelven las respuestas apropiadas. Las solicitudes y las respuestas se basan en la transferencia de representaciones de recursos. Los recursos son un conjunto de objetos direccionables, básicamente archivos y documentos, vinculados mediante URL. Como correctamente señaló Quentin anteriormente, el archivo REST simplemente implica que usaría los verbos HTTP GET / POST / PUT / DELETE ...

Solo ha proporcionado lo que parecen ser parámetros relativos en lugar de "ID" que es (o debería ser) concreto. Recuerde, las operaciones de obtención deben ser idempotentes (es decir, repetibles con el mismo resultado).