[[:desarrolladores:webservice_uso|Volver]]

----

===== Políticas =====

=====   =====

\\
Como ya expusimos el WS de suap no es solamente una especificación de intercambio de datos, es además una serie de políticas. Dichas políticas se van guiando mediante las secciones STATUS y VIEW que responde el WS de suap.

==== Política de persistencia. ====

Persistencia en el sentido de que se instanció un recurso en la base de datos de suap. La política es simple. Un recurso solo puede ser instanciado a requerimiento del consumidor mediante un método //**POST**//. Si el contenido del response contiene una sección REST con un atributo **token**diferente a **null**, entonces el recurso se persistió.

|Persistencia en el sentido de que se instanció un recurso en la base de datos de suap. La política es simple. Un recurso solo puede ser instanciado a requerimiento del consumidor mediante un método POST. Si el contenido del response contiene una sección REST con un atributo token diferente a null, entonces el recurso se persistió. En cualquier caso si no hay token entonces se puede desestimar la transacción previa puesto que no tuvo repercusión en suap. |

==== Política de acceso a un recurso. ====

Para poder acceder a un recurso es necesario contar con la URI del mismo (Uniform Resource Identifier. Uniform en el sentido de constante). En el caso del WS de suap si se cuenta con el **Token ** de un recurso se puede construir la URI del siguiente modo. \\
\\
**URI Base + ‘/’ + recurso en plural + ‘/’ + Token.** \\
\\
A modo de ejemplo tomemos por caso una orden cuyo token es 1234. En el entorno de test la URI de la misma sería: \\
\\
Uri Base = [[https://ws.test.suap.com.ar/procesador/doV2|https://ws.test.suap.com.ar/procesador/doV2]] \\
recurso = orden \\
token = O1234. \\
\\
**URI: [[https://ws.test.suap.com.ar/procesador/doV2/orden/O1234|https://ws.test.suap.com.ar/procesador/doV2/orden/O1234]]** \\
Mediante el método **GET**a dicha URI se obtendrán todos los datos del recurso.
==== Responsabilidad del WS de suap. ====

Suap garantiza la información del recurso de la forma mas completa posible y mediante dos modalidades que se expresan en dos secciones del Json de respuesta.

    * REST: Es la sección donde el recurso está detallado en terminos REST. Tomemos por ejemplo una orden cualquiera. En esta sección los atributos (fechas, estados de autorización, etc) estarán con sus valores, por el contrario los recursos relacionados (afiliado, prestador, prescriptor, etc) estarán representados por su URI.
    * RENDER: En esta sección se representa un recurso en un formato resuelto para el consumidor. A diferencia de REST los recursos relacionados están representados por una nueva clave que contiene información ya

==== Responsabilidad del consumidor ====

El consumidor del ws debe cumplir las siguientes responsabilidades:

    * Procesar la sección VIEW en cualquier POST (creación de un recurso)
    * En la generación de un recurso siempre debe existir un atributo que puede escribir el usuario libremente. (campo mágico)
    * Permitir al usuario hacer un GET de un recurso determinado con el procesamiento de la sección VIEW. Es decir, el consumidor podrá realizar los GETs que desee para administrar la sincronización entre su sistema y suap prescindiendo del procesamiento del view si lo deseara. Pero en algún lugar debe inlcuir un procesamiento de VIEW para el usuario.

\\