Desde este blog he escrito muchas veces sobre el porque la importancia del uso de la API Rest de SharePoint. El cambio en la forma de desarrollar en SharePoint, menos código en el servidor y mucho más peso en el cliente ha proporcionado que basemos nuestros desarrollos en una capa de servicios. Por este motivo la importancia del servicio Rest.
Ahora bien este servicio tal y como salio necesita diversas mejoras, algo que la primera vez que trabajas con ella te planteas dejarla de un lado y crear esta API tu mismo. Hay algunos desarrollos en los que es casi obligatorio, más que nada por la legibilidad del código y el performance de la propia aplicación.
Quizás viendo los cambios que se están abordando en Microsoft últimamente la opción correcta hubiera sido eliminar cualquier vinculación con el pasado y eliminar el servicio de _vti_bin de versiones anteriores.
Obtención de campos de tipo nombre
Uno de los aspectos más curiosos cuando comenzamos con la API Rest es tenemos una lista con la siguiente estructura:
Si ahora lanzo una consulta rest sobre esta lista atacando al endpoint del servicio REST «_api/list/GetbyTitle(‘Rest’)/items» y lo ejecuto bien en un navegador bien en una aplicación como Fiddler o Rest Console se visualiza además de toda la información complementaria al Item, toda la información de los elementos de la lista.
En el siguiente código muestro la inforación relativa a los valores del elemento 1 de esa lista.
"Id": 1,
"ContentTypeId": "0x0100C66202199E978747907F96EBF6DE3ABF",
"Title": "Elemento1",
"UsuariosId": 12,
"Taxonomia": {
"__metadata": {
"type": "SP.Taxonomy.TaxonomyFieldValue"
},
"Label": "1",
"TermGuid": "9cef583e-9335-4e03-97e2-a972f74b93c4",
"WssId": 1
},
Como podéis observar la información relativa al usuario que estaba almacenada en un campo de tipo Persona solamente me indica un 12. Ahora bien siguiendo las buenas practicas a la hora de crear una API Rest lo correcto es si quieres algo extra utilizamos el parámetro $expand e indicamos el campo que queremos expandir.
Entonces porque motivo el campo Taxonomía ya nos indica información complementaria al valor que esta almacenado? La verdad es que no entiendo el motivo de esta falta de criterio 🙁
Ahora bien, vayamos al problema yo quiero obtener el nombre del usuario para lo cual la primera aproximación que realizo es, como se que todos las listas de SharePoint tienen minimo un campo Title y un campo ID decido realizar esta consulta rest: «/_api/lists/getbytitle(‘Rest’)/items?$select=Usuarios/Title&expand=Usuarios/ID»
Cuando la ejecutamos nos devuelve el siguiente error:
{
"error": {
"code": "-1, Microsoft.SharePoint.SPException",
"message": {
"lang": "es-ES",
"value": "El campo de consulta 'Usuarios' no es v\u00e1lido. La cadena de consulta $select debe especificar los campos de destino y la cadena de consulta $expand debe contener Usuarios."
}
}
}
Se produce un error debido a que el campo Title no esta en la lista/tabla/servicio donde esta almacenada la información relativa al usuario. Ahora bien para poder consultar la información del mismo lo podemos realizar utilizando los datos que tiene un usuario como pueden ser Name, LastName, Department o SipAddress. Modificamos la consulta REST por la siguiente: «/_api/lists/getbytitle(‘Rest’)/items?$select= Usuarios/Name,Usuarios/LastName,Usuarios/Department&$expand=Usuarios/Id»
El resultado es el siguiente:
{
"d": {
"results": [{
"__metadata": {
"id": "e8f1f992-fa2e-41f1-b389-a15373f2c645",
"uri": "https://encaminaoffice365.sharepoint.com/_api/Web/Lists(guid'cad68435-4ef8-4697-83cb-432b923ddf32')/Items(1)",
"etag": "\"1\"",
"type": "SP.Data.RestListItem"
},
"Usuarios": {
"__metadata": {
"id": "12702d30-8c82-4ea1-b5a9-e0fd4c69b5f9",
"type": "SP.Data.UserInfoItem"
},
"Name": "i:0#.f|membership|office365dev@encaminaoffice365.onmicrosoft.com",
"LastName": "Lupi\u00e1\u00f1ez Maestro",
"Department": null
}
}]
}
}
Si realizamos esta misma petición pero al servición ODATA «/_vti_bin/listdata.svc/Rest?$select=Usuarios/Name&$expand=Usuarios/ID». Nos llevamos la siguiente sorpresa:
<error>
<code />
<message xml:lang="es-ES">Type 'Microsoft.SharePoint.DataService.ListaDeInformaciónDelUsuarioItem' does not have a property named 'ID'.</message>
</error>
Ahora bien como se hace con el servicio Odata?
Pues se hace siguiendo las buenas practicas, se indica que quieres visualizar el campo Usuarios y le aplicas el expand. Algo como esto: /_vti_bin/listdata.svc/Rest?$select=Usuarios&$expand=Usuarios
El resultado es el siguiente:
<d:Nombre>Olga Lupiáñez Maestro</d:Nombre> <d:Cuenta>i:0#.f|membership|office365dev@encaminaoffice365.onmicrosoft.com</d:Cuenta> <d:CorreoElectrónicoDelTrabajo>office365dev@encaminaoffice365.onmicrosoft.com</d:CorreoElectrónicoDelTrabajo>
<d:TeléfonoMóvil m:null="true" />
<d:AcercaDeMí m:null="true" />
<d:DirecciónSIP>office365dev@encaminaoffice365.onmicrosoft.com</d:DirecciónSIP>
<d:EsLaAdministraciónDelSitio m:type="Edm.Boolean">false</d:EsLaAdministraciónDelSitio>
<d:Eliminado m:type="Edm.Boolean">false</d:Eliminado>
<d:Oculto m:type="Edm.Boolean">false</d:Oculto>
<d:Imagen>https://encaminaoffice365-my.sharepoint.com:443/User%20Photos/Imagenes%20del%20perfil/office365dev_encaminaoffice365_onmicrosoft_com_MThumb.jpg?t=63508290143, https://encaminaoffice365-my.sharepoint.com:443/User%20Photos/Imagenes%20del%20perfil/office365dev_encaminaoffice365_onmicrosoft_com_MThumb.jpg?t=63508290143</d:Imagen>
<d:Departamento m:null="true" />
Conclusión
Creo que la API Rest va mejorando respecto a la versión inicial. Pero el realizar las cosas diferentes utilizando el servicio Rest u Odata hace que dificulte su adopción. Debería de estar de tratarse de forma standar independientemente de si utilizas la propia REST o el vti_bin. Sin conocer la funcionalidad interna da la sensación de que han ido implementando funcionalidades en la versión vti_bin y estas no las han integrado en la API Rest.
Aunque parezca una locura, se debería unificar el acceso a la API REST aunque ello conlleve romper con compatibilidades sobre versiones anteriores, en los últimos días estamos viendo como Microsoft está rompiendo con el pasado en algunos proyectos lease ASP vNext. Muchas veces observamos que no podemos evolucionar más un producto y la mejor forma es adaptarlo a un nuevo desarrollo mucho más adaptado a los tiempo, sino todavía seguiríamos desarrollando en ensamblador 🙂
¡Suscríbete a nuestras RRSS!
