[[:desarrolladores:webservice_uso|Volver]]

----

===== Obteniendo Recursos. =====

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. [[http://www.test.suap.com.ar/prestador.php|www.test.suap.com.ar/prestador.php]]
    * Credenciales para acceder que requirió por mail a suap.info@gmail.com
    * 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.

==== Método GET. ====

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**.

|**GET "https://ws.test.suap.com.ar/procesador/doV2/orden/O1234"  \\ El header de este request tiene auth basic + user:pass (token)**  |

==== Estructura general del response (respuesta). ====

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

|**<font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>Esquema de response general.</font>  ** \\ <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>{"REST": {…},      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“RENDER”: {…},      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“STATUS” : {…},      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“VIEW”: {…},      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>}</font>  |

    * **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.

| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>{</font>  \\ <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“REST”: {</font>  \\ <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“FechaRealizacion”:“2017-01-04 00:00:00”,</font>  \\ <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>- - -</font>  \\ <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“afiliado”:</font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“"https://ws.test.suap.com.ar/procesador/doV2/afiliado/7C9tIPdWMNTt99Zn1afALxroGVuQMt"]]”      \\  </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>,</font>  \\ <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>- - -</font>  \\ <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>}</font>  |

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.

| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>{      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>"RENDER": {      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>"FechaRealizacion": "2017-01-04 00:00:00",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>- - -      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>"afiliado":{ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>"NombreCompuesto": "CORBALAN MARTA LAURA ",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>"DocNumero": "10044895",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>"DocTipo": "DNI",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>"NumeroAfiliado": "15055729820800",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>"Token": "7C9tIPdWMNTt99Zn1afALxroGVuQMt",      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>- - -      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>}      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>}</font>  |

==== La sección VIEW del GET. ====

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.

[[:desarrolladores:seccion_view.png?616x398}}|{{  :desarrolladores:webservice_uso:seccion_view.png?nolink&616x398  }}]]

=== Acciones en la sección VIEW. ===

<font 9pt:normal/auto;;rgb(0,0,0);;#ffffff>FALTA DOCUMENTAR</font>

==== Accion search. ====

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:



| **POST** https://ws.test.suap.com.ar/procesador/doV2/afiliado.search |

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”:

| **POST** https://ws.test.suap.com.ar/procesador/doV2/search.afiliado \\ [{ “NombreCompuesto.contenga”:”Santiago” }] |

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

    * **REST**. Será una lista de las n primeras **URI**s 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 **URI**s.
    * **VIEW**.


|<font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>REQUEST https://ws.test.suap.com.ar/procesador/doV2/afiliado.search]]]]]]]]]]]]  \\
</font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>{    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“REST”:{    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“1”:“https:ws….V2/afiliados/YMABXGMrPMo0iDFs1lVeGSvhLEWwPq”,    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>- - -    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“10”:https://ws....V2/afiliados/ges37O3Ne007vZyM4OnGIpj0cEzm4N]]]]]]]]]]]]”    \\
</font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>}, </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff> \\ “STATUS”: {      \\ “ERROR”: [],      \\ “NOTICE”: {      \\ “More”: true,      \\ “ActualPage”: 1,      \\ “PageSize”: 100      \\ }      \\ }      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>,    \\ “RENDER”:{      \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“1”:{    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“NombreCompuesto”: “MU OZ SANTIAGO SEGUNDO ”,    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“DocNumero”:”    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>- - -    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>}    \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>}</font> |

En la sección **STATUS **      aparece una sección NOTICE en la que se nos indica una serie de datos útiles para el paginado:<font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff> \\ </font>

    * 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.

|**<font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>POST "https://ws.test.suap.com.ar/procesador/doV2/afiliado.search/1 "   \\  </font> ** <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>{     \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>“NombreCompuesto.contenga”:”Santiago”</font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff> \\ </font> <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>}</font>  |




=== Mantenerse al día. ===

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:

|<font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>https://ws.test.suap.com.ar/procesador/doV2/obraSocial.search]]]]]]  \\  {       \\  “Nombre.contenga”:””       \\  }</font>  |

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.

| \\  <font 10pt:normal/Courier;;rgb(0,0,0);;#ffffff>{    \\ “REST”: {       \\ “1”: “https://ws.test.../28EiEf2G0gP49RtFighfflHBZXk1tu]]]]]]”,    \\  “2”: “https://ws.test.../mAJU8wAVBgU4GgLQGhX9JTXUO6wDrX]]]]]]”,    \\  “3”: “https://ws.test.../Gy226GrRazQ8yNjYXawYB7ikv3C6xI]]]]]]”    \\  },       \\  “STATUS”: {       \\  “ERROR”: [],       \\  “pagina”: 1,       \\  “cantidadTotal”: 3,       \\  “cantidadPorPagina”: “10”       \\  },       \\  “RENDER”: {       \\  “1”: {       \\  “Nombre”: “PAMI”,       \\  - - -       \\  },       \\  “2”: {       \\  “Nombre”: “ACA SALUD”,       \\  - - -       \\  },       \\  “3”: {       \\  “Nombre”: “Sancor Salud”,       \\  - - -       \\  }       \\  }       \\  }</font>  |

\\