Lo mejor para comenzar es hacer una serie de ejemplos. En este punto usted debería contar con:

• URL de un sitio de test para prestador. www.test.suap.com.ar/prestador.php
• Credenciales para acceder que requirió por mail a [email protected]
• Un token de usuarios que gestionó en el sitio para prestadores de ejemplo
• URI base del WS de test: https://ws.test.suap.com.ar/procesador/doV2

Para proceder con este capítulo es necesario contar con ordenes creadas desde la página web. Puede consultar al personal administrativo del punto de atención que desea conectar a su software de consumo de WS como se realiza esta operación en la web de testing.

Es el método utilizado para obtener un recurso mediante su URI. Para avanzar con el ejemplo en la página de suap puede mirar la lista de ordenes. Verá que las mismas tienen un número. Ese número con el agregado de una O delante es el token de la orden en tanto recurso para el WS. Con eso podremos armar la URI de un recurso orden para hacer un GET y comenzar a analizar el response.

Un response producto de un GET es un Json que contiene las siguientes secciones principales:

• REST. Es el o los recursos en términos REST. Los atributos del recurso base más las URIs de los recursos relacionados. Aquí encontraremos los “links” de los recursos relacionados y nada mas. Consumir la información desde esta sección es mas trabajoso ya que requiere de mayor cantidad de consultas al WS, pero permite resolver cualquier situación no prevista ya que literalmente se puede navegar por toda la información.
• RENDER. Es la misma información de la sección REST pero ya preparada (renderizada) para que el consumidor la disponga sin tener que acceder a los recursos relacionados. El objetivo de esta sección es bajar la taza de uso del WS, facilitando toda la información necesaria para el consumidor en la menor cantidad posible de transacciones.
• STATUS. Sección que indica estados de las transacciones. Por ejemplo los errores en la sección interna ERROR
• VIEW. Es información que debe ser presentada al usuario y una especificación de como se debe requerir información faltante para cumplir con los requisitos mínimos

Para ejemplificar veamos como se obtiene un atributo y un recuros en la sección REST y RENDER. Por caso la fecha de realización como atributo y el afiliado como recurso.

En el fragmento inferior vemos que la fecha de realización es el valor de la fecha, es decir, es un atributo. En cambio el recurso afiliado es una URI. Si hiciermos GET a esa URI obtendríamos toda la infomación del recurso.

El mismo response pero en la sección RENDERpresenta la información mas apropiada para consumir sin realizar mas consultas. Con respecto a los atributos vemos que no hay diferencia, en cambio con los recursos asociados sí. Del afiliado observamos que tenemos información mas completa y útil sin la necesidad de hacer mas requests al WS.

La sección VIEW es una pequeña “vista” o formulario con opciones que debe ser presentada al usuario. El consumidor tiene la libertad de realizar GET para mantener sincronizado su sistema con suap sin la intervención del usuario, pero debe ofrecer al menos una forma de acceder al GET de los recursos procesando la sección VIEW del response.

En el caso del método que nos ocupa el VIEW en la mayoría de los casos contendrá acciones.

FALTA DOCUMENTAR

Otro modo de obtener recursos es mediante la accion search. Se crean mediante el método POST y devuelven como response una lista de recursos que coinciden en los criterios de búsqueda especificados.

Se debe especificar en la URI del POST el “recursoABuscar” + “.” + “search” . Es decir, supongamos que buscamos un afiliado, la URI en testing sería:

En el content debemos especificar los atributos y/o recursos relacionados mas sus atributos separados por puntos “.” y finalmente la operación de comparación. Veamos por ejemplo el caso de buscar todos los afiliados que contienen el nombre “Santiago”:

Si seguimos el ejemplo veremos que nos devuelvo un response que contiene 3 secciones:

• REST. Será una lista de las n primeras URIs de los recursos que satisfacen esta condición.
• STATUS. Información sobre el resultado de la transacción. En el caso de la acción search se incorpora una sección además de ERROR. La sección NOTICE permite saber tres cosas, si queda una página mas, cuantos se muestran por página y que página se está mostrando.
• RENDER. Es la misma información que en REST pero ya procesada para consumir sin la necesidad de recorrer las URIs.
• VIEW.

En la sección STATUS aparece una sección NOTICE en la que se nos indica una serie de datos útiles para el paginado:

• More: es un boolean que indica si hay mas páginas (true) o si estamos en la ultima (false)
• PageSize: es la cantidad máxima de elementos que se muestran por página (no es la cantidad actual)
• ActualPage: es la página actual.

Si deseáramos avanzar de página se indica, repitiendo el post con todo el contenido, en la uri como un parámetro. Quedaría “nombreRecurso”.search/n donde n es el número de página.

La obtención de recursos mediante search sirve para actualizar datos de convenios en el LIS. Supongamos un POST al recurso search.obrasSociales con el siguiente content:

Tendremos como response la lista de los convenios que están siendo gestionados por suap en este momento. Además esa lista, como siempre, contendrá las URIs de cada uno para poder recorrerlos y obtener información relevante para el sistema del consumidor. Por ejemplo valores de unidades, nomencladores, etc.