Vamos a tratar de explicar en una serie de posts, qué es y en qué consiste el protocolo oData. El protocolo oData es utilizado por las aplicaciones SAPUI5 para realizar todas las transacciones de datos con el back-end ya sea a través del Gateway, XS Engine (con HANA) u oData Provisioning (con SCP).

Las principales características del protocolo oData:
- Está basado en el protocolo de comunicación HTTP, por lo que sus recursos pueden ser accedidos y editados con simples mensajes HTTP.
- Los recursos están definidos en un modelo abstracto de datos que está basado en el Entity Data Model, que veremos más adelante.
- Utiliza URIs para la identificación de los recursos.
- Permite las operaciones CRUD (create, read, update, delete) sobre los recursos de una forma estandarizada.
- Utiliza los formatos de datos: XML y JSON.
Cada servicio oData está representado por una URI, llamada la URI raíz del servicio. Existen dos documentos asociados al servicio oData que sirven para describirnos el servicio a través de llamadas GET HTTP:
- Service Metadata Document: describe el modelo de datos, es decir, la estructura y relaciones entre todos los recursos expuestos por el servicio. Como hemos dicho anteriormente, necesitamos una URI para acceder a los recursos y, por tanto, para acceder a los metadatos necesitamos añadir a la URI raíz del servicio $metadata.

En este modelo de datos aparecen en escena los Entity Types, Entity Sets, Complex Types, Associations y Functions Import. Todo esto lo veremos en detalle en los próximos posts.
- Service Document: que muestra todos los Entity Sets que componen el servicio. Lo solicitamos desde la URI raíz del servicio y nos puede devolver la información en XML (sin hacer nada) o en formato JSON (añadiendo a la URI raíz $format=json).

Antes de ver cómo está formado el Entity Data Model, quería indicar como el protocolo oData realiza operaciones de creación, lectura, actualización y eliminación en recursos mediante la utilización de métodos HTTP tal y como muestra la siguiente figura:

Con esto doy por cerrada esta introducción a los servicios oData, posteriormente iré profundizando en el Entity Data Model, en su generación desde Gateway, en los componentes de la URI y en cómo ejecutar estas peticiones desde nuestras aplicaciones SAPUI5, hasta el próximo post.