Este artículo proviene de un motor de traducción automática.

Puntos de datos

Crear y consumir con formato JSON OData

Julie Lerman

Descargar el ejemplo de código

En mi columna de junio, "Datos enlazar OData en Web Apps con Knockout.js" (msdn.microsoft.com/magazine/jj133816), algunos me divertí mucho con Knockout.js y OData. Como aprendí cómo datos enlazar Knockout a los resultados del servicio OData, también encontré más información sobre OData y JSON que había conocido. En la columna de este mes, voy cambiar mi enfoque a consumir JSON de OData y crear JSON-friendly WCF Data Services.

Te voy a mostrar cómo consumir JSON directamente desde JavaScript, cómo aprovechar el SDK de JavaScript de OData (llamado datajs) y cómo asegurar su alimentación es lo suficientemente flexible como para soportar cualquier estilo de codificación del cliente que necesitará JSON.

OData es una especificación para garantizar que los consumidores del servicio de datos pueden contar con una experiencia coherente de los servicios que se consumen. Una de las reglas de la especificación es que OData resultados son salida por defecto en formato ATOM (que es una forma específica de formato XML), y que puede también salida resultados en formato JSON.

A medida que evoluciona la especificación OData, introduce nuevas características que puede de su servicio a los usuarios aprovechar. Después de discutir las diversas formas para consumir y crear JSON en OData feeds, voy a hacer que usted entienda cómo próximos cambios a la voluntad de especificaciones de OData afectan OData y lo que puede hacer hoy para estar preparado. Comenzaré por exponer a un cliente con el siguiente esquema en mi servicio:

public class Customer
{
  public int Id { get; set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string AccountNumber { get; set; }
}

De forma predeterminada, un resultado de cliente de mi servicio sería datos de átomo y mirar (como el formato con un navegador) como se muestra en la figura 1.

Resultados de la figura 1 como átomo

El mismo resultado de salida como JSON sería:

{"d":[
{"__metadata":{"id":"http://localhost:43447/DataService.svc/Customers(1)",
               "uri":"http://localhost:43447/DataService.svc/Customers(1)",
               "type":"DataAccessMSDNJuly2012.Customer"},
  "Id":1,
  "FirstName":"Julie",
  "LastName":"Lerman",
  "AccountNumber":"A123"}
]}

Si está trabajando con los crudos resultados de átomo o JSON, el formato de la salida puede hacer una gran diferencia en la facilidad de codificación. Por ejemplo, si está consumiendo el alimento en JavaScript, es mucho más fácil trabajar directamente con un objeto JSON que tienen que analizar XML.

Hay dos formas de asegurar los resultados regresan en formato JSON: puede especificar aplicación/json en el encabezado de solicitud o puede agregar un parámetro de consulta de OData. Al redactar peticiones en Fiddler para probar, es muy fácil agregar un encabezado, como se muestra en la figura 2.

Figura 2 especificación JSON en el encabezado de solicitud

También puede agregar un encabezado en JQuery cuando construyes tu solicitud, pero gracias a un par de otras opciones, no tienes que ir a esa longitud. Una de estas opciones es utilizar el datajs, la biblioteca de JavaScript para OData, que proporciona muchos otros beneficios para codificación contra OData así. La otra opción es utilizar el parámetro de consulta de OData, $formato.

Obtener JSON por defecto con datajs

Puede descargar datajs de datajs.codeplex.com. A partir del momento de la escritura, la versión actual es la 1.0.3.

Si utiliza Visual Studio, puede agregar directamente a un proyecto mediante el gestor de paquetes de NuGet datajs. NuGet agregará una carpeta scripts al proyecto y poner la versión actual de datajs (datajs-1.0.3.js) y sus archivos de script de min relacionados en esa carpeta.

La biblioteca de scripts proporciona una clase denominada OData que facilita a leer y escribir desde feeds compatible con OData y proporciona otras características. Aunque fácilmente puede insertar un encabezado en la solicitud a través de la función de OData.read, no es necesario. De forma predeterminada, datajs agregará automáticamente el encabezado porque si utiliza esta biblioteca, es probable que desee JSON.

Aquí hay algunos JavaScript que se llama OData.read, que pasa en el identificador Uri que representa mi consulta del servicio de datos y especifica qué hacer con los resultados (en este caso, yo estoy almacenando los resultados en una variable denominada cliente):

    <script src="Scripts/datajs-1.0.2.js" type="text/javascript"></script>
    <script type="text/javascript" charset="utf-8">
      var customer;
      OData.read({ requestUri:"http://localhost:43447/DataService.svc/Customers?$top=1"
                 },
                 function (data, response) {
                   customer = data.results[0];
                 },
                 function (err) {
                   alert("Error occurred: " + err.message);
                 });
    </script>

Como depurar a través de este script, puedo ver que el resultado de la consulta es un objeto, como se muestra en la figura 3.

Figura 3 vista de JSON resultado de depuración

Con Fiddler para capturar el tráfico HTTP, puedo ver que el encabezado Accept, especificando aplicación/json, formaba parte de esta solicitud.

Si eres un desarrollador PHP, debe desproteger la biblioteca relacionada, OData SDK para PHP (odataphp.codeplex.com). Igual que la biblioteca de datajs para los desarrolladores de JavaScript, el SDK de PHP asegura que los resultados son relevantes. Pero en este caso, lo hace por solicitar el formato ATOM y, a continuación, materializando los datos resultantes del átomo en objetos PHP.

Solicitando JSON con el formato $ parámetro

No todo el mundo que necesitan JSON va a utilizar la biblioteca de datajs. Pero eso no significa necesariamente que tienes que usar el encabezado de solicitud para pedir JSON. La especificación de OData también tiene un parámetro de consulta, $formato, que acepta json como uno de sus valores.

Aquí es el Uri modificado que pide JSON directamente:

http://localhost:43447/DataService.SVC/Customers (1)?$ formato = json

Puede agregar el parámetro format $ para cualquier consulta. Aquí estoy combinando la solicitud de formato con un filtro:

http://localhost:43447/DataService.SVC/Customers?$Filter=FirstName eq 'Julie' & formato = json

Obligando a un servicio de datos para honrar el formato $ parámetro

Aunque el uso de este parámetro de formato para solicitar que JSON es parte de la especificación de OData, no cada servicio de datos sabe cómo procesar el parámetro.De hecho, cuando se crea un servicio de datos de WCF .net, devuelve átomo por defecto.Así, mientras que el servicio aceptará el formato $= parámetro de json, todavía volverá átomo en la respuesta.Pero algunos desarrolladores en el equipo de OData han compartido una solución sencilla (disponible en archive.msdn.microsoft.com/DataServicesJSONP) puede agregar a la aplicación que permite WCF Data Services para procesar el $ comando de formato y volver a JSON.

La extensión se suministra en forma de una clase denominada JSONPSupportInspector y un atributo denominado JSONP­SupportBehavior.Ambas clases aprovechan la lógica de System.Component­modelo.Puede agregar las clases directamente a su proyecto o crear un conjunto de ellos para hacer referencia a.Una vez su servicio WCF de datos tiene acceso a estas clases, todo lo que necesita hacer es agregar el atributo JSONPSupportBehavior a la clase de servicio, así:

[JSONPSupportBehavior]
public class DataService : DataService<SalesContext>
{
  public static void InitializeService(DataServiceConfiguration config)
  {
    config.SetEntitySetAccessRule("Customers", EntitySetRights.All);
    config.SetEntitySetAccessRule("Orders", EntitySetRights.All);
  }

Con este atributo en su lugar, mi servicio responderá al formato $= parámetro de json cuando lo añado en la consulta, y mi servicio volverá JSON.

Estoy escribiendo esta columna en los talones de la versión de abril de 2012 de WCF Data Services 5, que aún requiere agregar explícitamente el apoyo JSONP a sus servicios de datos. Si desea ver esta envuelto en la API de servicios de WCF datos en el futuro, puede agregar un voto para UserVoice característica sugerencias el equipo a bit.ly/ImeTQt.

Soporte JSON y versiones de OData

La especificación de OData está actualmente en versión 2 y evolucionando. Trabajo en versión 3 está en marcha, con documentación de la versión beta ya disponible en OData.org. De forma predeterminada, el servicio de datos de WCF se destino versión 1. Lamentablemente, el valor predeterminado no funcionará si desea utilizar una función de la versión 2 OData, como paginación del servidor, que está disponible en WCF Data Services. He agregado a mi servicio para demostrar la configuración SetEntitySetPageSize:

public static void InitializeService(DataServiceConfiguration config)
  {
    config.SetEntitySetAccessRule("Customers", EntitySetRights.All);
    config.SetEntitySetAccessRule("Orders", EntitySetRights.All);
    config.SetEntitySetPageSize("Customers", 3);
  }

Con esta característica de la versión 2 en su lugar, el servicio será una excepción y decirle que tiene que especificar MaxProtocolVersion mayor que la versión 1. Aquí está el error asociado a la configuración de SetEntitySetPageSize:

"Paginación del lado del servidor no puede ser usado cuando el MaxProtocol­versión del servicio de datos está establecida en DataServiceProtocolVersion.V1."

Para corregir el problema, es fácil de establecer la versión del código de servicio:

public static void InitializeService(DataSeviceConfiguration config)
  {
    config.SetEntitySetAccessRule("Customers", EntitySetRights.All);
    config.SetEntitySetAccessRule("Orders", EntitySetRights.All);
    config.SetEntitySetPageSize("Customers", 3);
    config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
  }

Y, en este caso, es todavía posible pedir salida JSON en el encabezado de solicitud o mediante el parámetro de formato de $ en el identificador Uri.

Sin embargo, puede diseñar su servicio para ser compatibles con el avance, estableciendo la MaxProtocolVersion en DataServiceProtocol­Version.V3. Pero en la versión 3, cambiará el formato JSON a un formato más ágil de salida llamado luz de JSON (bit.ly/JrM6RQ). Esto puede ser un gran problema si la aplicación cliente no espera el formato JSON optimizado. Desde la perspectiva de la aplicación consume, parecerá que la solicitud de JSON ha sido ignorada porque átomo será devuelto y no JSON.

Eso es porque su cliente debe explícitamente el formato más detallado de solicitud o especificar la versión de OData a destino. Sin cualquiera de estas reglas satisfechas, el servicio volverá a ATOM. Por lo tanto, usted debe hacer una u otra de las tareas necesarias para obtener resultados JSON cuando el servicio se ajusta a la versión 3.

Aquí es un encabezado de solicitud modificado para solicitar específicamente el formato detallado de JSON:

Aceptar: aplicación/json; odata = verbose

Y aquí está un ejemplo de la cabecera con una petición específica que la respuesta de OData utiliza el formato de la versión 2:

Aceptar: aplicación/json

MaxDataServiceVersion: 2.0

¿Qué pasa si está utilizando el formato $= parámetro de json en la consulta en lugar de solicitar JSON en el encabezado? Una vez más, el servicio no comprender la solicitud y obtendrá un error indicando que no se admite el tipo MIME. En este caso debe incluir la MaxDataServiceVersion en el encabezado de la solicitud.

Sin embargo, si utiliza datajs, no necesita preocuparse. Comenzando con la versión 1.0.3, la biblioteca es consciente de la necesidad de la información de versión y proporciona en sus peticiones. En este lugar, el servicio está listo para OData versión 3 y los consumidores tienen la flexibilidad de solicitar cualquier formato de la versión que les gusta.

JSON en el oleoducto de OData

Gracias a su formato simplificado, JSON es un formato cada vez más importante para los desarrolladores. Ustedes recordarán que incluso algunas de las nuevas bases de datos de documento escribí en la columna de puntos de datos de noviembre de 2011, "qué diablos son bases de datos de documento?" (MSDN.Microsoft.com/Magazine/hh547103), almacenar datos utilizando JSON o algún giro en JSON.

Si se retira de la columna de puntos de datos del mes pasado, encontrará ejemplos de lectura y escritura a los servicios de datos usando JSON y Knockout.js.

A medida que avanzamos en una edad cuando están desconectadas más y más aplicaciones, apreciará la capacidad de consumir OData como JSON (en ya sea detallado o el nuevo formato más eficiente). Y si va a crear servicios, sus consumidores seguramente estaremos agradecidos si se puede hacer fácil para ellos acceder a los datos de esta manera.

Julie Lerman es una MVP de Microsoft, mentora y consultora de .NET que vive en las colinas de Vermont. Puede encontrarla haciendo presentaciones sobre acceso de datos y otros temas de Microsoft .NET en grupos y congresos de usuarios alrededor del mundo. Mantiene un blog en thedatafarm.com/blog y es la autora de “Programming Entity Framework” (O’Reilly Media, 2010) y “Programming Entity Framework: Code First” (O’Reilly Media, 2011). Puede seguirla a través de Twitter en twitter.com/julielerman.

Gracias al siguiente experto técnico por su ayuda en la revisión de este artículo: Alejandro Trigo