Header Ads Widget

Ticker

6/recent/ticker-posts

Descripción general del estándar OData

 


Uno de los aspectos más importantes del desarrollo moderno es la interoperabilidad. La capacidad no solo de codificar algo bien sino de hacerlo compatible con una amplia gama de contrapartes eleva incluso las funciones básicas a algo más.

La forma en que la industria implementa la interoperabilidad es importante: un estándar es tan bueno como la cantidad de personas que lo aceptan como estándar. Más importante aún, un estándar solo es bueno si es realmente interoperable, y no simplemente un conjunto comúnmente aceptado de posibles implementaciones (es decir, debe aplicarse de manera uniforme, no de forma específica).

Un estándar de datos que ha ganado fuerza en los últimos años es OData  (Protocolo de datos abiertos). ¿Qué es exactamente OData y cómo se ve en la práctica? En este artículo, vamos a sumergirnos en el estándar OData, su historia y ejemplos de código para demostrar su uso en la práctica.

Historia de OData como estándar

En este artículo, revisamos OData, un estándar OASIS aprobado por ISO / IEC que define un conjunto de mejores prácticas para crear y consumir API RESTful.

Microsoft lanzó por primera vez el estándar OData en 2007 como Protocolo de datos abiertos. Mientras desarrollaba el estándar, Microsoft lanzó las versiones 1.0, 2.0 y 3.0 bajo la promesa de especificación abierta de Microsoft, que es un programa de Microsoft que promete que Microsoft no buscará ninguna "reclamación necesaria de Microsoft" contra los desarrolladores que utilizan OData en algunos casos cubiertos generales.

En 2014, la versión 4.0 fue estandarizada por la Organización para el Avance de Estándares de Información Estructurada ( OASIS ). En 2015, OASIS presentó OData v4.0 y el formato OData JSON v4.0 asociado a ISO / IEC JTC 1, un comité técnico de la Organización Internacional de Normalización ( ISO ). Desde entonces ha sido ratificado como estándar ISO.

Toda la premisa detrás de OData fue el desarrollo de un protocolo abierto para consultar las API RESTful y garantizar que sean interoperables entre sí. Como tal, OData aprovecha muchas RFC del Grupo de trabajo de ingeniería de Internet ( IETF ), incluidas las especificaciones HTTP 1.1, las especificaciones de publicación Atom, JSON y más. OData está en una posición única para la interoperabilidad, considerando cuánto aprovecha las tecnologías existentes para hacer lo que hace.

¿Qué aspecto tiene OData?

Entonces, ¿cómo se ve realmente OData? Debido a que OData utiliza muchos enfoques REST estándar y RFC estándar, gran parte de su infraestructura debería parecer relativamente familiar. OData usa URI para identificar sus recursos y ofrece algunos elementos fijos que se adjuntan al servicio OData propiamente dicho.

El documento de servicio  enumera las entidades dentro del servicio de destino, las funciones utilizables entre esas entidades y cualquier singleton. Este documento está diseñado para permitir una navegación similar a la de los hipermedia de las aplicaciones de integración de OData. El documento de metadatos describe los tipos, funciones, conjuntos y acciones que comprende el servicio OData. Estos metadatos proporcionan una especie de comprensión contextual al cliente que interactúa con el servicio OData, lo que permite a los clientes consultar e interactuar con las entidades del servicio.

Estos dos documentos son, con mucho, los elementos más importantes del sistema OData, ya que ayudan a los clientes a comprender no solo lo que representa el servicio OData, sino también cómo interactuar con esos recursos de una manera comprensible y útil.

En términos de la interacción real con el servicio OData, debido a que OData usa verborrea estándar, su funcionalidad es bastante familiar:

  • GET - Se usa para recuperar el recurso para renderizar, transformar, etc. GET puede invocar un flujo, una propiedad de navegación, una colección de entidades - sin importar el tipo, GET se usa para llamar a esos recursos.
  • POST - Se usa para crear un nuevo recurso.
  • PUT: Se utiliza para actualizar un recurso existente. Tenga en cuenta que el uso de PUT reemplaza el contenido del recurso por completo con el recurso actualizado.
  • PATCH- Por el contrario, PATCH se utiliza para actualizar un recurso existente solo en parte. La actualización de propiedades específicas de la instancia (o, en este caso, una parte de una instancia) se realiza a través de PATC; la sustitución completa se realiza mediante PUT.
  • DELETE - Como era de esperar, esto elimina (o elimina, como se le suele llamar) el recurso.

XOData : un visualizador y explorador de servicios / API de OData para permitir la creación rápida de prototipos, la verificación, las pruebas y la documentación de las API de OData. Muestra cortesía de PragmatiQa. Véalo aquí .

Ejemplos de código

Quizás OData se entienda mejor en la práctica. A lo largo de este documento, incluiremos algunos ejemplos de código de la documentación y desglosaremos secciones específicas para una mayor comprensión.

Devolver una colección de entidades

Primero, veamos una solicitud básica para una colección de entidades. Como se indicó anteriormente, usaremos el verbo GET para hacerlo:

GET serviceRoot/People

Como resultado, obtenemos la siguiente carga útil en respuesta:

{
"@odata.context": "serviceRoot/$metadata#People",
"@odata.nextLink": "serviceRoot/People?%24skiptoken=8",
"value": [
{
"@odata.id": "serviceRoot/People('russellwhyte')",
"@odata.etag": "W/"08D1694BD49A0F11"",
"@odata.editLink": "serviceRoot/People('russellwhyte')",
"UserName": "russellwhyte",
"FirstName": "Russell",
"LastName": "Whyte",
"Emails": [
"Russell@example.com",
"Russell@contoso.com"
],
"AddressInfo": [
{
"Address": "187 Suffolk Ln.",
"City": {
"CountryRegion": "United States",
"Name": "Boise",
"Region": "ID"
}
}
],
"Gender": "Male",
"Concurrency": 635404796846280400
},
......
,
{
"@odata.id": "serviceRoot/People('keithpinckney')",
"@odata.etag": "W/"08D1694BD49A0F11"",
"@odata.editLink": "serviceRoot/People('keithpinckney')",
"UserName": "keithpinckney",
"FirstName": "Keith",
"LastName": "Pinckney",
"Emails": [
"Keith@example.com",
"Keith@contoso.com"
],
"AddressInfo": [],
"Gender": "Male",
"Concurrency": 635404796846280400
}
]
}

Si bien la carga útil de respuesta se comprende con bastante facilidad, hay algunas cosas interesantes que señalar. En primer lugar, veamos esta sección de la carga útil:

{
"@odata.context": "serviceRoot/$metadata#People",
"@odata.nextLink": "serviceRoot/People?%24skiptoken=8",

Estos dos enlaces presentan algunos metadatos interesantes que ayudan a los clientes a navegar por el recurso tal como se devuelve. En primer lugar, el @odata.contextenlace le da al cliente un contexto de propiedad importante en términos de su relación con el servicio en general. Esto, cuando se le brindan datos contextuales adicionales mediante el uso del odata.nextLinkenlace (que define que los datos devueltos son solo un subconjunto de una colección mayor, y también dónde encontrar los siguientes elementos de esa colección), permite que el cliente interactúe con la carga útil. y datos asociados de una forma mucho más eficaz.

Si bien esta solicitud es bastante clara, también es extremadamente pesada. Intentemos hacer una solicitud específica para una entidad individual. En este ejemplo, la solicitud se realiza mediante un ID específico:

GET serviceRoot/People('russellwhyte')

Esto generará la siguiente carga útil:

{
"@odata.context": "serviceRoot/$metadata#People/$entity",
"@odata.id": "serviceRoot/People('russellwhyte')",
"@odata.etag": "W/"08D1694BF26D2BC9"",
"@odata.editLink": "serviceRoot/People('russellwhyte')",
"UserName": "russellwhyte",
"FirstName": "Russell",
"LastName": "Whyte",
"Emails": [
"Russell@example.com",
"Russell@contoso.com"
],
"AddressInfo": [
{
"Address": "187 Suffolk Ln.",
"City": {
"CountryRegion": "United States",
"Name": "Boise",
"Region": "ID"
}
}
],
"Gender": "Male",
"Concurrency": 635404797346655200
}

Tenga en cuenta aquí que la ID es la misma que la URL de la entidad; es una convención que la ID sea idéntica al enlace del recurso. En una situación como esta, donde el nombre de usuario es el mismo que el ID de la entidad y, por lo tanto, la URL, es posible que la entrada se duplique en varios campos. Eso no significa que sean lo mismo o que se usen de la misma manera, independientemente del valor repetido.

De nota adicional aquí está esta sección:

    "@odata.etag": "W/"08D1694BF26D2BC9"",

Aquí, vemos un etag, que es una etiqueta de entidad que se genera para reflejar el estado actual del recurso. Este valor de cadena se puede usar en solicitudes posteriores para ver si la entidad ha tenido algún cambio; debido a cómo se generan los etags, si el etag es diferente, algo en la entidad ha cambiado. Esto es útil para rastrear el estado, pero la etiqueta también es un excelente método de rastreo para establecer fuentes de verdad.

También puede abordar una propiedad de entidad simplemente agregando el segmento de ruta con el nombre de la propiedad a la URL de la entidad; por ejemplo, en la documentación, se indica la siguiente solicitud para recuperar el Nombre de la propiedad de la entidad de una entidad serviceRoot:

GET serviceRoot/Airports('KSFO')/Name

Esto dará como resultado la siguiente respuesta de carga útil:

{
"@odata.context": "serviceRoot/$metadata#Airports('KSFO')/Name",
"value": "San Francisco International Airport"
}

Poder solicitar propiedades de entidades individuales es otra herramienta poderosa para detectar cambios de estado. Por ejemplo, si el valor del estado es pertinente para el cumplimiento del pedido, rastrear la identificación de la entidad para los cambios generales y luego verificar el estado de la propiedad para el envío cumplido puede ser una excelente manera de transmitir el estado a un cliente. Este sistema de almacenamiento de entidades tiene un millón de usos diferentes, y es genial verlo implementado en este estándar.

Consultas de compatibilidad

OData también admite bastantes opciones para consultar datos. Estas opciones de consulta se agregan como una variable a la solicitud de URL y transforman la carga útil y los datos resultantes. Por ejemplo, queríamos filtrar una solicitud GET a una persona específica que podríamos usar:

GET serviceRoot/People?$filter=FirstName eq ‘Scott’

En este caso, $ filter = se usa para determinar cuál es exactamente el objetivo del filtro. A partir de aquí, podemos usar eq para establecer que el filtro debe ser igual a un valor establecido; en este caso, "Scott". Esto generará datos para las entradas siempre que la entrada tenga el valor de FirstName "Scott". Esto se puede usar para devolver respuestas filtradas muy específicas cuando solo conoce un alias o un nombre secundario, pero no el valor real de la propiedad.

También puede utilizar filtros anidados para devolver contenido junto con un valor anidado filtrado. Por ejemplo, en la documentación, se utiliza la siguiente invocación:

GET serviceRoot/People?$expand=Trips($filter=Name eq 'Trip in US')

Esto es único en el sentido de que devuelve entidades adjuntas a "Viaje en EE. UU." En forma de salida de URL de personas. En esencia, una función de búsqueda compleja se filtra y devuelve de una manera fácil de entender con una solicitud relativamente ligera.

Hay algunas opciones de consulta más generales que pueden afectar la salida propiamente dicha. $orderbypermite al cliente solicitante ordenar en orden ascendente (usando "asc") o en orden descendente (desc). $toppermite que el solicitante incluya el número de elementos extraídos de la colección para ser procesados ​​como parte de la solicitud, lo que permite una vista de un vistazo de la relación de los datos de salida con la colección completa. Por el contrario, le $skippermite ver la cantidad de elementos de la colección que no están incluidos en los resultados. $countpermite al cliente obtener el número total de recursos coincidentes en la respuesta.

Esta es solo una pequeña muestra de los tipos de consultas que se pueden utilizar en OData. Basta decir que OData tiene una amplia gama de opciones de consulta.

Empresas que utilizan OData

Muchas empresas utilizan OData en una amplia gama de subsecciones de la industria. IBM utiliza OData como parte de sus ofertas DB2 e Infomix, Data Server Gateway para OData y WebSphere eXtreme Scale, centrándose en aumentar la interoperabilidad del cliente al exponer las estructuras de OData.

Microsoft obviamente usa el estándar de manera bastante activa, con soporte en Lightswitch, Dyanamics CRM y más. SAP Gateway utiliza OData para conectar "cualquier lenguaje o modelo de programación" a las aplicaciones de SAP. Webnodes CMS usa OData tiene uno de sus formatos de datos compatibles.

OData es una opción muy poderosa y, dado que forma parte de un conjunto abierto de estándares , es probable que la lista de socios crezca significativamente con el tiempo.

Conclusión

OData es una opción bastante poderosa, y su valor solo se consolida aún más por el hecho de que es un estándar abierto. Poder tener una solución estandarizada e interoperable para datos que también es ampliamente utilizada por socios respetados de la industria abre el desarrollo a una mayor facilidad de consumo, expresibilidad y cooperación plug-and-play con otras soluciones.

¿Qué opinas sobre OData? ¿Es el estándar que todos estábamos esperando? Déjame saber abajo en los comentarios.

Publicar un comentario

0 Comentarios