MINISTERIO DE MODERNIZACIÓN
SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA
Resolución 19/2018
Ciudad de Buenos Aires, 02/03/2018
VISTO la Ley N° 25.506, los Decretos Nros. 434 del 1° de Marzo de 2016, 561 del 6 de Abril de 2016, 1273 del 19 de Diciembre de 2016, 894 del 1° de noviembre de 2017, la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN (RESOL-2017-6-APN-SECMA#MM) y el Expediente Electrónico N° EX-2018-09329996- -APN-SECMA#MM, y
CONSIDERANDO:
Que la Ley N° 25.506 de Firma Digital, reconoció la eficacia jurídica del documento electrónico, la firma electrónica y la firma digital, y en su artículo 48 estableció que el Estado Nacional, dentro de las jurisdicciones y entidades comprendidas en el artículo 8° de la Ley N° 24.156, promoverá el uso masivo de la firma digital de tal forma que posibilite el trámite de los expedientes por vías simultáneas, búsquedas automáticas de la información y seguimiento y control por parte del interesado, propendiendo a la progresiva despapelización.
Que el Decreto N° 434 del 1° de Marzo de 2016 aprobó el Plan de Modernización del Estado con el objetivo de alcanzar una Administración Pública al servicio del ciudadano en un marco de eficiencia, eficacia y calidad en la prestación de servicios, contemplando como segundo eje el desarrollo, mejora continua e integración de sistemas de gestión, planteando como objetivo incorporar nuevos sistemas y aprovechar iniciativas ya desarrolladas e implementadas que permitan encontrar soluciones transversales de administración integradas al Sistema de Gestión Documental y Expediente Electrónico, procurando cambiar el modelo de desarrollo sectorial, hacia uno homogéneo y cohesionado, para lo cual prevé como actividad definir los estándares tecnológicos para promover la interoperabilidad de los sistemas y evitar que el ciudadano tenga que aportar información ya obrante en la Administración.
Que el Decreto N° 561 del 6 de Abril de 2016 aprobó la implementación del sistema de Gestión Documental Electrónica – GDE, como sistema integrado de caratulación, numeración, seguimiento y registración de movimientos de todas las actuaciones y expedientes del Sector Público Nacional, facultando en su artículo 6° a la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar las normas complementarias, aclaratorias y operativas necesarias para la implementación de dicho sistema y el funcionamiento de los sistemas informáticos de gestión documental.
Que el artículo 2 del mencionado Decreto N° 561 del 6 de Abril de 2016 dispuso su ámbito de aplicación, alcanzando a las entidades y jurisdicciones enumeradas en el artículo 8 de la Ley N° 24.156 que componen el Sector Público Nacional.
Que el Decreto N° 1273 del 19 de Diciembre de 2016 dispuso que las entidades y jurisdicciones enumeradas en el artículo 8 de la Ley N° 24.156 que componen el Sector Público Nacional, deberán intercambiar la información pública que produzcan, obtengan, obre en su poder o se encuentre bajo su control con cualquier otro organismo público que así se lo solicite.
Que el mencionado Decreto N° 1273 del 19 de Diciembre de 2016 facultó a la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar los protocolos de intercambio, pautas de interoperabilidad, normas complementarias, aclaratorias, técnicas y operativas necesarias para el cumplimiento de lo dispuesto en su Artículo 1ro.
Que el Decreto N° 894 del 1° de Noviembre de 2017, que aprobó el “Reglamento de Procedimientos Administrativos Decreto N° 1759/72 T.O. 2017”, estableció que las autoridades administrativas actuarán de acuerdo con los principios de sencillez y eficacia, procurando la simplificación de los trámites, y facilitando el acceso de los ciudadanos a la administración a través de procedimientos directos y simples por medios electrónicos.
Que, en ese orden de ideas, el Anexo I del citado Decreto N° 894 del 1° de Noviembre de 2017, que aprobó el “Reglamento de Procedimientos Administrativos Decreto N° 1759/72 T.O. 2017”, dispuso en su artículo 107 la eliminación de cargas al administrado, disponiendo que, en aquellos casos que para la sustanciación de un procedimiento administrativo sea necesaria la presentación de alguna información, dato, documento o certificado que deba ser emitido por otra entidad o jurisdicción del Sector Público Nacional, la entidad responsable del procedimiento lo solicitará directamente por comunicación oficial al organismo responsable de su producción y certificación, agregando que la solicitud del dato, información, documentación o certificado deberá expresar el motivo, el procedimiento en el cual se enmarca, y la norma que justifica su presentación.
Que en función de lo establecido en el artículo 2° del Decreto N° 1273 del 19 de Diciembre de 2016, la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM) aprobó las “Pautas Técnicas de Interoperabilidad” y los procedimientos aplicables al intercambio de información de carácter público entre los organismos comprendidos en el mencionado Decreto N° 1273/2016.
Que la mencionada Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM) estableció el efecto positivo del silencio de la Administración, favorable a la continuación del trámite, en el marco del Decreto N° 1273 del 19 de Diciembre de 2016, en aquellos casos en los cuales un organismo requiera información a otro, y el organismo productor de la información no contestare en un plazo de CINCO (5) días.
Que el aludido Decreto N° 1273 del 19 de Diciembre de 2016 instruyó a las entidades y jurisdicciones enumeradas en el artículo 8º de la Ley Nº 24.156 a celebrar convenios de colaboración recíproca con organismos provinciales, municipales, de la Ciudad Autónoma de Buenos Aires o entes públicos no estatales, para potenciar el deber de intercambio de información pública en el territorio nacional.
Que en esta instancia del proceso de modernización de la Administración Pública Nacional, resulta oportuno instrumentar un módulo de interoperabilidad que facilite a los organismos comprendidos en el Decreto N° 1273 del 19 de Diciembre de 2016 el intercambio de información en forma segura y directa, aliviando de cargas al administrado en los casos que un organismo requiera determinada información, dato, documento o certificado que deba ser emitido por otra entidad o jurisdicción del Sector Público Nacional.
Que este módulo de interoperabilidad actuará como nexo entre los sistemas informáticos y bases de datos de los organismos alcanzados por el Decreto N° 1273 del 19 de Diciembre de 2016, facilitando así el intercambio de información entre ellos, y posibilitando una respuesta rápida, segura, con información actualizada, y con valor jurídico, en un marco de seguridad y confianza.
Que resulta necesario a tal efecto implementar el módulo de Interoperabilidad (Interoper.ar) del sistema de Gestión Documental Electrónica – GDE, así como actualizar las “Pautas de Interoperabilidad” y los procedimientos aplicables para el intercambio de información entre los organismos comprendidos en el artículo 8 de la Ley N° 24.156, en reemplazo de los aspectos definidos en la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM).
Que, en consecuencia, resulta oportuno derogar la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM)
Que la DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA DIGITAL dependiente de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA y la SUBSECRETARÍA DE GESTIÓN ADMINISTRATIVA de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA se han expedido en los ámbitos de su competencia.
Que la presente medida se dicta en ejercicio de las facultades conferidas por el artículo 6° del Decreto N° 561/2016 y por el artículo 2° del Decreto N° 1273/16.
Por ello,
EL SECRETARIO DE MODERNIZACIÓN ADMINISTRATIVA DEL MINISTERIO DE MODERNIZACIÓN
RESUELVE:
ARTÍCULO 1°.- Apruébase la implementación del Módulo de Interoperabilidad (INTEROPER.AR) del sistema de Gestión Documental Electrónica – GDE como plataforma de intercambio seguro de la información pública que produzcan, obtengan, obre en su poder o se encuentre bajo el control de las entidades y jurisdicciones comprendidas en el Decreto N° 1273 de fecha 19 de Diciembre de 2016.
ARTÍCULO 2°.- El módulo INTEROPER.AR funciona como un nodo de intercambio entre los distintos sistemas de información y bases de datos de los organismos alcanzados por el Decreto N° 1273 de fecha 19 de Diciembre de 2016.
ARTÍCULO 3°.- La DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA DIGITAL dependiente de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA será responsable de:
a) Administrar el módulo INTEROPER.AR.
b) Ejercer el rol de autenticador de las aplicaciones de los organismos proveedores de los datos.
c) Establecer los procedimientos de alta y baja de los sistemas de información y bases de datos proveedores de datos.
d) Administrar el Directorio Interno de Servicios del módulo INTEROPER.AR.
ARTÍCULO 4°.- Las entidades y jurisdicciones responsables de los sistemas de información y bases de datos, ejercerán el rol de administración de sus propias aplicaciones, autorizarán las consultas a sus respectivas bases de datos en base a reglas propias de autorización y acceso a sus datos.
ARTÍCULO 5°.- Apruébase el documento “Descripción del Módulo de Interoperabilidad - INTEROPER.AR” que como Anexo I (IF-2018- 09344965- APN- DNSAYFD#MM) forma parte de la presente Resolución.
ARTÍCULO 6°.- Apruébanse las “Pautas Técnicas de Interoperabilidad de Sistemas” que como Anexo II (IF 2018-09344892-APN -SSGA#MM) forma parte de la presente Resolución.
ARTÍCULO 7°.- Establécese que, en el caso de información que no esté disponible en el módulo INTEROPER.AR, las entidades y jurisdicciones enumeradas en el artículo 8° de la Ley N° 24.156 que componen el Sector Público Nacional deberán intercambiar la información pública que produzcan, obtengan, obre en su poder o se encuentre bajo su control, con cualquier otro organismo público que así se lo solicite, de acuerdo a los siguientes procedimientos:
a) En los casos que la información requerida necesaria para la sustanciación de actuaciones no sea recurrente, el organismo solicitante deberá enviar una Nota a través del módulo Comunicaciones Oficiales (CCOO) del sistema de Gestión Documental Electrónica – GDE, para cada caso, detallando la información solicitada, la necesidad y la norma en la cual se fundamenta la solicitud.
b) En los casos que la información necesaria para la sustanciación de actuaciones sea recurrente, pero alguno de los dos Organismos no contara con la información requerida en un sistema informático, el organismo solicitante deberá enviar una nota mediante el módulo Comunicaciones Oficiales (CCOO) del sistema de Gestión Documental Electrónica – GDE, para cada caso, detallando la información solicitada, la necesidad y la norma en la cual se fundamenta la solicitud.
c) En los casos que la información necesaria para la sustanciación de actuaciones administrativas sea recurrente y ambos Organismos cuenten con la información requerida en un sistema informático, el organismo solicitante y el organismo productor de la información podrán realizar el intercambio automático de información mediante el módulo INTEROPER.AR, o bien mediante la interoperabilidad de sus sistemas, de acuerdo con las Pautas Técnicas de Interoperabilidad aprobadas en el Anexo II. A tal fin, el organismo requirente deberá solicitar al organismo productor de la información el establecimiento del mecanismo de consulta y respuesta automática, mediante el envío por única vez de una Nota a través del módulo Comunicaciones Oficiales (CCOO) del sistema de Gestión Documental Electrónica – GDE, mencionando la necesidad y la norma que fundamenta la solicitud de información.
ARTÍCULO 8°.- Establécese que en los casos que el intercambio de información no sea realizado a través del módulo INTEROPER.AR, el organismo productor de la información deberá responder en un plazo máximo de CINCO (5) días hábiles, salvo que estuviere expresamente establecido otro plazo.
ARTÍCULO 9°.- Establécese que en los casos en que la información solicitada sea pasible de ser respondida en forma afirmativa o negativa, y habiendo transcurrido el plazo de CINCO (5) días hábiles previsto en el artículo anterior sin respuesta del organismo productor de la información, el organismo solicitante considerará el silencio como favorable a la prosecución del trámite.
ARTÍCULO 10.- Derógase la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM).
ARTÍCULO 11.- Comuníquese a la SINDICATURA GENERAL DE LA NACIÓN – SIGEN.
ARTÍCULO 12.- Comuníquese, publíquese, dése a la DIRECCIÓN NACIONAL DEL REGISTRO OFICIAL y archívese. — Eduardo Nicolás Martelli.
NOTA: El/los Anexo/s que integra/n este(a) Resolución se publican en la edición web del BORA -www.boletinoficial.gob.ar-.
Número: IF-2018-09344965-APN-DNSAYFD#MM
Referencia: Anexo I - Módulo de Interoperabilidad INTEROPER.AR
I.- Propósito
El presente documento tiene como objetivo definir las características del módulo de INTEROPERABILIDAD, en adelante INTEROPER.AR, administrado por la DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA DIGITAL, dependiente de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN
II.- Breve descripción de INTEROPER.AR
El presente documento describe el módulo INTEROPER.AR del Sistema de Gestión Documental Electrónica - GDE.
INTEROPER.AR es una capa de interoperabilidad que permite la interoperabilidad y el intercambio seguro de datos entre sistemas informáticos de gobierno.
Los organismos alcanzados por el Decreto N° 1273/2016 pueden utilizar el módulo INTEROPER.AR para facilitar, por ejemplo, la gestión de oficios judiciales, la tramitación interna que requiere datos o información disponible en otro organismo, o el suministro a terceros de datos o información en forma ágil, segura y con valor legal.
III.- Composición
1.- INTEROPER.AR se compone de:
1.1. El módulo de interoperabilidad que puede ser adoptado por todos los organismos que exponen sus servicios
1.2. Un esquema de autenticación, reglas y protocolos para facilitar las comunicaciones de forma directa y segura entre sistemas
1.3. Un Directorio de servicios
1.4. El Marco normativo
1.5. La Autoridad Central de administración del módulo.
1.6. Los sistemas informáticos o bases de datos distribuidas de las entidades y jurisdicciones proveedores de información.
2. - La autenticación entre sistemas informáticos o bases de datos que utilizan el modulo INTEROPER.AR está basada en estándares, es administrada por un organismo central pero la autorización y las bases de datos y los servicios permanecen distribuidos y autónomos, bajo la administración y exclusivo control de las entidades o jurisdicciones que los implementan.
3. - Conectarse a INTEROPER.AR permite a los organismos ahorrar costos y tiempos, porque acceden a una multiplicidad de servicios y bases de datos ofrecidos por otros organismos sin la dificultad de desarrollar soluciones para cada integración. Además le garantiza que todas las solicitudes de información que le llegan a través de INTEROPER.AR están debidamente autenticadas por un órgano central. La administración y autorización de quién accede a los datos propios del organismo se mantiene bajo exclusivo control de cada jurisdicción.
4. - INTEROPER.AR es un acelerador para el desarrollo de mejores soluciones al ciudadano, porque permite aplicaciones y servicios más inteligentes, que no preguntan lo que el Estado ya sabe y le acercan al ciudadano la información que requiere, sin imponer barreras innecesarias basadas en estructuras organizacionales.
5. - INTEROPER.AR provee a los organismos respuestas con total valor jurídico, emitidas por la autoridad competente para responder en función de las competencias sustantivas que posee y los datos que administra, ya que cada dato es provisto por el organismo que tiene competencia sobre él. Evita la duplicidad de datos, los padrones y bases de datos no actualizadas, las inconsistencias entre sistemas, brindando un servicio de respuesta automática, con datos actualizados.
6. - INTEROPER.AR garantiza el origen y el valor probatorio de cada solicitud y de cada respuesta, porque cada una tiene asociada una firma digital del sistema que la emite.
IV.- Funcionamiento
1.- Autenticación de los sistemas informáticos y bases de datos.
El módulo INTEROPER.AR brinda un servicio de autenticación de los sistemas informáticos y bases de datos que lo integran.
Este servicio de autenticación está centralizado en la autoridad que lo administra, la DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA DIGITAL, que gestiona las altas y bajas de los sistemas informáticos y bases de datos en el módulo INTEROPER.AR.
2.- Directorio interno de servicios.
El certificador a su vez mantiene un servicio dentro de INTEROPER.AR que es el directorio interno de servicios. Este directorio contiene toda la información necesaria para conectarse a los demás nodos de INTEROPER.AR - tanto información de uso, como documentación de APIs y endpoints, incluyendo también información de ubicación dentro de la red.
3. - Publicación de servicios.
Una vez que un sistema informático o base de datos está conectado a INTEROPER.AR puede publicar servicios usando los estándares de interoperabilidad vigentes y consumir los servicios de otros sistemas.
Cada invocación a un servicio se realiza punto a punto. Esto hace a la red robusta y tolerante a fallas y más segura, ya que no hay un solo punto de falla. Cada solicitud emitida o recibida es autenticada, cifrada y registrada para auditoría.
4. - Proveedores de servicios.
El modulo INTEROPER.AR facilita la interacción entre los organismos, ya que prevé su interoperabilidad, mediante un procedimiento sencillo y robusto desde el punto de vista de seguridad informática y jurídica.
Para integrar un sistema provisto por otro miembro de INTEROPER.AR, el organismo debe consultar el servicio de directorio. Con la información del directorio se realiza una conexión directa hacia el proveedor del servicio. Esta conexión puede ser por internet. El solicitante remite a través de INTEROPER.AR una solicitud de servicio con firma digital y se la envía al proveedor del servicio. El proveedor del servicio verifica la firma digital de la solicitud, verifica contra la Autoridad Central la validez de la firma y aplica reglas propias de autorización y acceso a sus datos. En caso de autorizar la transacción entonces devuelve una respuesta firmada digitalmente. Ambos participantes almacenan la evidencia de la operación.
V.- Marco Normativo.
El marco normativo que sustenta al módulo INTEROPER.AR está conformado por la Ley N° 25.506, los Decretos Nros. 434 del 1° de Marzo de 2016, 561 del 6 de Abril de 2016, 1273 del 19 de Diciembre de 2016, 894 del 1° de noviembre de 2017 y la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN (RESOL-2017- 6-APN - SECMA#MM).
En efecto, la Ley N° 25.506 de Firma Digital, reconoció la eficacia jurídica del documento electrónico, la firma electrónica y la firma digital, y en su artículo 48 estableció que el Estado Nacional, dentro de las jurisdicciones y entidades comprendidas en el artículo 8° de la Ley N° 24.156, promoverá el uso masivo de la firma digital de tal forma que posibilite el trámite de los expedientes por vías simultáneas, búsquedas automáticas de la información y seguimiento y control por parte del interesado, propendiendo a la progresiva despapelización.
Por otra parte, el Decreto N° 434 del 1° de Marzo de 2016 aprobó el Plan de Modernización del Estado con el objetivo de alcanzar una Administración Pública al servicio del ciudadano en un marco de eficiencia, eficacia y calidad en la prestación de servicios, contemplando como segundo eje el desarrollo, mejora continua e integración de sistemas de gestión, planteando como objetivo incorporar nuevos sistemas y aprovechar iniciativas ya desarrolladas e implementadas que permitan encontrar soluciones transversales de administración integradas al Sistema de Gestión Documental y Expediente Electrónico, procurando cambiar el modelo de desarrollo sectorial, hacia uno homogéneo y cohesionado, para lo cual previó como actividad definir los estándares tecnológicos para promover la interoperabilidad de los sistemas y evitar que el ciudadano tenga que aportar información ya obrante en la Administración.
Adicionalmente, resulta consecuencia de lo dispuesto por el Decreto N° 561 del 6 de Abril de 2016, que aprobó la implementación del sistema de Gestión Documental Electrónica - GDE, como sistema integrado de caratulación, numeración, seguimiento y registración de movimientos de todas las actuaciones y expedientes del Sector Público Nacional, facultando en su artículo 6° a la SECRETARIA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar las normas complementarias, aclaratorias y operativas necesarias para la implementación de dicho sistema y el funcionamiento de los sistemas informáticos de gestión documental.
Pero fundamentalmente, el módulo INTEROPER.AR es consecuencia de lo establecido en el Decreto N° 1273 del 19 de Diciembre de 2016, que dispuso la obligación de las entidades y jurisdicciones enumeradas en el artículo 8 de la Ley N° 24.156 que componen el Sector Público Nacional a intercambiar la información pública que produzcan, obtengan, obre en su poder o se encuentre bajo su control con cualquier otro organismo público que así se lo solicite.
El mencionado Decreto N° 1273 del 19 de Diciembre de 2016 facultó a la SECRETARIA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar los protocolos de intercambio, pautas de interoperabilidad, normas complementarias, aclaratorias, técnicas y operativas necesarias para el cumplimiento de lo dispuesto en su artículo 1°.
En tal sentido, la SECRETARIA DE MODERNIZACIÓN ADMINISTRATIVA emitió la Resolución N° 6 de fecha 10 de Enero de 2017, en la cual estableció, por una parte, las 'Pautas Técnicas de Interoperabilidad' y además, los procedimientos de intercambio de información, estableciendo el efecto positivo del silencio de la administración.
Efectivamente, la mencionada Resolución N° 6/2017 estableció que, en el marco del Decreto N° 1273 del 19 de Diciembre de 2016, cuando un organismo requiera información a otro, y el organismo productor de la información no contestare en un plazo de CINCO (5) días, se le reconocerá al silencio sentido positivo.
Complementariamente, el Decreto N° 894 del 1° de Noviembre de 2017, que aprobó el 'Reglamento de Procedimientos Administrativos Decreto N° 1759/72 T.O. 2017', estableció que las autoridades administrativas actuarán de acuerdo con los principios de sencillez y eficacia, procurando la simplificación de los trámites, y facilitando el acceso de los ciudadanos a la administración a través de procedimientos directos y simples por medios electrónicos.
En ese orden de ideas, el Anexo I del citado Decreto N° 894 del 1° de Noviembre de 2017, que aprobó el 'Reglamento de Procedimientos Administrativos Decreto N° 1759/72 T.O. 2017', dispuso en su artículo 107 la eliminación de cargas al administrado, disponiendo que, en aquellos casos que para la sustanciación de un procedimiento administrativo sea necesaria la presentación de alguna información, dato, documento o certificado que deba ser emitido por otra entidad o jurisdicción del Sector Público Nacional, la entidad responsable del procedimiento lo solicitará directamente por comunicación oficial al organismo responsable de su producción y certificación. La solicitud del dato, información, documentación o certificado deberá expresar el motivo, el procedimiento en el cual se enmarca, y la norma que justifica su presentación.
En síntesis, en esta instancia del proceso de modernización de la Administración Pública Nacional, resulta oportuno instrumentar una medida que simplifique los trámites administrativos, eliminando de cargas al administrado en los casos que un organismo requiera determinada información, dato, documento o certificado que deba ser emitido por otra entidad o jurisdicción del Sector Público Nacional.
Ello así, y a los efectos de lograr una modernización efectiva de la gestión administrativa del Estado, es esencial contar con una herramienta de interoperabilidad que permita el intercambio directo entre organismos de documentación y datos que actualmente se le solicitan al particular, facilitando de manera permanente el acceso, consulta y transferencia de información pública para lograr la interconexión y operación simultánea.
Número: IF-2018-09344892-APN-SSGA#MM
Referencia: Anexo II - Pautas Técnicas de Interoperabilidad de Sistemas
I. - Introducción
Las presentes 'Pautas Técnicas de Interoperabilidad de Sistemas' tienen por objeto brindar un marco de intercambio de información entre las entidades y jurisdicciones que integran el Sector Público Nacional, en el marco del Decreto Nro. 1273/2016.
Las interfaces de programación de aplicaciones (APIs) exponen las funciones internas de un sistema al mundo exterior. Esto permite que los sistemas compartan información sin requerir que los desarrolladores tengan que compartir el código de las aplicaciones, ni entender las complejidades internas de cada sistema.
II. - Alcances
A los fines de facilitar el intercambio de información entre las entidades y jurisdicciones que componen el Sector Público Nacional, de acuerdo a lo dispuesto en el Decreto Nro. 1273 del 19 de diciembre de 2016, se establecen las siguientes Pautas de Interoperabilidad. Las entidades y jurisdicciones detalladas en el artículo 8 de la Ley Nro. 24.156 deberán intercambiar la información desarrollando APIs siguiendo los siguientes lineamientos.
Estas 'Pautas Técnicas de Interoperabilidad de Sistemas' son de aplicación para todas las entidades y jurisdicciones que integran la Administración Pública Nacional o Entidades de derecho Público vinculadas o dependientes de aquélla (en adelante, organizaciones) que participan en el intercambio de asientos registrales, ya sea para la prestación de servicios directos a los ciudadanos, como de cara al intercambio de información con otros órganos.
III. - Arquitectura REST
Las 'Pautas Técnicas de Interoperabilidad de Sistemas' se basan en la arquitectura REST. Dicha arquitectura especifica un conjunto de principios de arquitectura de Software que definen la interacción entre distintos componentes dentro de un sistema de hipermedia distribuido. En particular, se implementará arquitectura REST sobre el protocolo HTTP.
Los principios generales a los que deberán ajustarse son:
- Arquitectura cliente-servidor: Un cliente realiza peticiones a un servidor, el cual devuelve respuestas.
- Stateless: Cada petición que se realiza será independiente de la siguiente.
- Cacheable: Una vez realizada la primera petición, el resto podrán ser obtenidas del cache en caso de no haber sufrido cambios.
- Sistema por capas: Para toda petición originada de un cliente al servicio no será distinguible si está siendo dirigida directo al servidor o a un sistema de chache o balanceador.
- Identificación del recurso: Se deberá indicar a través de una URI, la misma debe cumplir con el RFC 3986.
- Operaciones uniformes: Los métodos serán los especificados en HTTP (GET, PUT, POST, DELETE) provistos en el RFC 2616.
- Formato o representación del recurso: El tipo de contenido deberá ser del tipo JSON, el mismo se encuentra definido en el RFC 7159 https://tools.ietf.org/html/rfc7159
IV.- Pautas en el diseño
- Se debe crear una URI para cada recurso. Estos deben ser sustantivos, no verbos.
No se debe utilizar: http://www.ejemplo.com.ar/entidades/obtenerentidad?id=001
Se debe utilizar: http://www.ejemplo.com.ar/entidades/001
Use los verbos HTTP (GET, POST, PUT, DELETE) para funcionar en las colecciones y elementos.
Ponga el número de versión en la URL, por ejemplo: http://ejemplo.gob.ar/vL0/path/to/resource
Especificar campos opcionales como una lista separada por coma.
Para indicar el formato de respuesta utilizar el campo content-type del header siendo por defecto el formato JSON. Por ejemplo: XML: Content-Type: application/xml JSON: Content-Type: application/json; charset=utf-8
El formato DEBE ser del tipo: api/v2.0/resource/{id}
Utilizar sub recursos para indicar relaciones.
Si un recurso está relacionado a otro, se deberá representar como un sub recurso del mismo. Ejemplo: /organismos/{id del organismo}/empleados/{id_empleado}
No obstante es válido y muchas veces necesario que exista /empleados como top-level uri dentro de la API.
En el caso de que una representación incluya una lista de objetos relacionados debe incluir links a las URI de cada objeto.
De otra forma sólo se puede navegar el árbol de relación teniendo información externa a los resultados que indique dónde ir a buscar cada recurso.
Una URi que apunta a un sub-recurso (ej, /organismos/{id_organismo}/empleados/ 123 puede devolver la representación del sub-recurso o simplemente utilizar un redirect http para indicar el top-level que lo devuelve (ej HTTP 307 moved temporarily)
- Categorizar los recursos de acuerdo a las acciones que los clientes pueden realizar sobre los mismos, por ejemplo una representación del recurso o modificación.
Para las representaciones, se deben utilizar el verbo HTTP GET.
Para las modificaciones, se deben utilizar los verbos HTTP POST, PUT y/o DELETE.
- Los request GET no deben tener efectos sobre el recurso al que apuntan. Sólo deben devolver su representación. Por lo tanto, invocar al recurso no debería tener como resultado modificarlo.
- Manejo de errores y respuestas usando códigos HTTP estándar
Usar los códigos de estado HTTP para indicar el resultado de las invocaciones a la API. Los más importantes son los siguientes:
- 200 ,201,204
- 304, 307
- 400,401,403,404,422
- 500
Las respuestas de errores DEBEN incluir los códigos de estados HTTP, mensaje para el desarrollador, mensaje para el usuario final, código de error interno, enlaces con documentación al respecto. Por ejemplo:
{
'status' : 400,
'developerMessage' : 'Descripción clara del problema. Sugerencias de cómo resolver el problema.', 'userMessage' : 'Este es el mensaje para el usuario final.', 'errorCode' : '[444444|exceptionName]',
'moreInfo' : 'http://www.ejemplo.gob.ar/developer/path/to/help/for/444444,
http://drupal.org/node/444444',
}
- Mantener en minúsculas la URI.
- Usar UTF-8 y aceptar caracteres 'especiales' como comillas, tildes, símbolos.
- Esconder las extensiones de las tecnologías utilizadas (.php, .asp, .jsp, etc).
- Se deberá utilizar como encoding UTF8, y deberá ser informado en la cabecera (Conten-tType: application/json; charset=utf-8)
- Se deberán utilizar fechas según ISO 8601 en UTC Para solo fechas, el formato debe ser 2016-01-27.
Para fechas completas, el formato debe ser 2016-01-27T10:00:00Z.
- Una API que retorna JSON DEBE usar el content type adecuado al tipo de datos y encoding que devuelve.
El recomendado es:
Content-Type: application/json; charset=utf-8
Ejemplos válidos de URLs Lista de artículos:
GET http://www.ejemplo.gob/api/vL0/articulos
Filtrando con query string:
GET http://www.ejemplo.gob/api/v1.0/articulos?year=2016&sort=desc
Un artículo en formato JSON:
GET http://www.ejemplo.gob/api/vL0/articulos/1234
Todos los comentarios de un artículo en particular:
GET http://www.ejemplo.gob/api/vL0/articulos/1234/comentarios
Especificar campos opcionales en una lista separada por coma:
GET http://www.ejemplo.gob/api/v1.0/articulos/1234?fields=title,body
Agregar un comentario a un artículo específico:
POST http://ejemplo.gob/api/vL0/articulos/1234/comentarios
Ejemplos NO válidos de URLs:
Sustantivos singulares: http://www.ejemplo.gob/api/vL1/articulo http://www.ejemplo.gob/api/vL1/articulo/1234
Verbo en la URL: http://www.ejemplo.gob/api/vL1/articulo/1234/create
Filtro fuera del query string http://www.ejemplo.gob/api/vL1/articulos/2016/desc
V.- Verbos HTTP
Los verbos HTTP, o métodos, se deben utilizar en el cumplimiento de sus definiciones de la norma HTTP/1.1 .
Este es un ejemplo de cómo deben ser los verbos HTTP para crear, leer, actualizar y eliminar las operaciones en un contexto particular:
VI.- Soporte JSON
- Las respuestas DEBEN ser objetos JSON (no arrays). Usar un array para retornar resultados limita la capacidad de incluir metadata sobre resultados, y limita la capacidad de las API's para agregar top-level keys en el futuro.
- Se puede incluir un parámetro especial para devolver los datos en otros formatos como XML, CSV u otro.
GET http://www.ejemplo.gob/api/v1.0/articulos?format=csv
GET http://www.ejemplo.gob/api/vL0/articulos.csv
- No usar claves impredecibles. Realizar el parsing de una respuesta JSON donde las claves son impredecibles es difícil.
- Usa guión_bajo para las claves. Diferentes lenguajes usan diferentes convenciones. JSON usa guión_bajo, no camelCase.
Más info en json.org
VII.- Documentación
Para documentar los Servicios WEB REST se debe incluir una introducción funcional que describa qué hace la API, y para cada servicio lo siguiente:
Nombre
URI
Ejemplo de uso incluyendo invocación con curl y la respuesta del ejemplo.
Descripción de los parámetros obligatorios y opcionales
Valores por default Códigos de error.
Ejemplo de documentación
Listar Reparticiones Obtiene la lista de reparticiones
Uso: curl 'http://ejemplo.gob.ar/api/v1/reparticiones' -H 'Authorization: tokendeautenticacion'
El comando anterior devuelve una respuesta JSON como :
{
items: [
{
'id': 1,
'name': 'reparticionl',
'propiedad': 'valor'
},
{
'id': 2,
'name': 'reparticion2',
'propiedad': 'valor'
},
]
}
Este endpoint devuelve las reparticiones según los parámetros de filtro HTTP Request
GET http://example.com/api/kittens
Parámetros del request: Parametro Default Descripción
incluir_externos false Si está en true, la respuesta incluye reparticiones externas.
activas true Si está en false, la respuesta incuirá reparticiones que no están activan en el sistema
Nota — Este servicio no requiere autenticación.
También se admitirá utilizar herramientas de documentación como: SWAGGER MkDocs Aglio
Documentar los ejemplos de la forma mas genérica posible, contemplando mas de un lenguaje de ser posible (por ejemplo Python y Java)
VIII. - Seguridad
Con el objetivo de ofrecer escalabilidad, y generar servicios WEB stateless (sin estado) y aptos para aplicaciones móviles, se deberá implementar seguridad a través de los siguientes lineamientos:
Autenticación Basada en Tokens
Se implementará a partir de JSON WEB TOKEN (JWT) explicado en el RFC 7519 utilizando para asegurarlo los estándares JWS y JWE (RFC 7515 y 7516) utilizándo como mínimo el algoritmo HMAC
Protocolo de comunicación segura
La implementación de los servicios WEB RESTFul deberá ser implementada en https para ofrecer encriptación.
IX. - Versiones
Nunca libere la versión de una API sin su número de versión.
Los números de versión deben abarcar dos niveles de versión: x.x
Las versiones DEBEN ser enteros, no decimales, con el prefijo 'v'.
Dar soporte al menos una versión anterior a la actual.
Ejemplos: Válido: v1.0, v2.1, v3.5 No válido: v-1.1, v1.2.5, 1.3.3
X.- Casos particulares
Para algunos tipos de intercambio de información deben tenerse especial cuidado en la arquitectura de las APIs para que sean efectivas. Algunos casos particulares que pueden requerir complementar REST con otros protocolos son:
a) Transferencias Masivas. Cuando el cliente requiera tener una copia propia de un set de datos muy grande por motivos válidos (implementar un motor de búsqueda, hacer procesos de inteligencia de negocio, etc). Si la API no puede transmitir la información de forma eficiente o escalable (para el cliente como para el servidor) puede ser necesario implementar otros métodos.
b) Notificaciones inmediatas. Las APIs REST funcionan a pedido del cliente. En el caso de que el cliente deba tener las últimas modificaciones o novedades de forma inmediata se pueden implementar métodos tipo callback (si el servidor lo permite) o tecnologías de streaming de datos, publisher subscriber, etc. De ser posible deben mantenerse sobre HTTP (utilizando websockets, Server Sent Events,etc)
c) Transacciones costosas. Las transacciones que disparan operaciones muy costosas deben implementarse de forma asincrona, evitando bloquear a los sistemas que las ejecutan.
SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA
Resolución 19/2018
Ciudad de Buenos Aires, 02/03/2018
VISTO la Ley N° 25.506, los Decretos Nros. 434 del 1° de Marzo de 2016, 561 del 6 de Abril de 2016, 1273 del 19 de Diciembre de 2016, 894 del 1° de noviembre de 2017, la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN (RESOL-2017-6-APN-SECMA#MM) y el Expediente Electrónico N° EX-2018-09329996- -APN-SECMA#MM, y
CONSIDERANDO:
Que la Ley N° 25.506 de Firma Digital, reconoció la eficacia jurídica del documento electrónico, la firma electrónica y la firma digital, y en su artículo 48 estableció que el Estado Nacional, dentro de las jurisdicciones y entidades comprendidas en el artículo 8° de la Ley N° 24.156, promoverá el uso masivo de la firma digital de tal forma que posibilite el trámite de los expedientes por vías simultáneas, búsquedas automáticas de la información y seguimiento y control por parte del interesado, propendiendo a la progresiva despapelización.
Que el Decreto N° 434 del 1° de Marzo de 2016 aprobó el Plan de Modernización del Estado con el objetivo de alcanzar una Administración Pública al servicio del ciudadano en un marco de eficiencia, eficacia y calidad en la prestación de servicios, contemplando como segundo eje el desarrollo, mejora continua e integración de sistemas de gestión, planteando como objetivo incorporar nuevos sistemas y aprovechar iniciativas ya desarrolladas e implementadas que permitan encontrar soluciones transversales de administración integradas al Sistema de Gestión Documental y Expediente Electrónico, procurando cambiar el modelo de desarrollo sectorial, hacia uno homogéneo y cohesionado, para lo cual prevé como actividad definir los estándares tecnológicos para promover la interoperabilidad de los sistemas y evitar que el ciudadano tenga que aportar información ya obrante en la Administración.
Que el Decreto N° 561 del 6 de Abril de 2016 aprobó la implementación del sistema de Gestión Documental Electrónica – GDE, como sistema integrado de caratulación, numeración, seguimiento y registración de movimientos de todas las actuaciones y expedientes del Sector Público Nacional, facultando en su artículo 6° a la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar las normas complementarias, aclaratorias y operativas necesarias para la implementación de dicho sistema y el funcionamiento de los sistemas informáticos de gestión documental.
Que el artículo 2 del mencionado Decreto N° 561 del 6 de Abril de 2016 dispuso su ámbito de aplicación, alcanzando a las entidades y jurisdicciones enumeradas en el artículo 8 de la Ley N° 24.156 que componen el Sector Público Nacional.
Que el Decreto N° 1273 del 19 de Diciembre de 2016 dispuso que las entidades y jurisdicciones enumeradas en el artículo 8 de la Ley N° 24.156 que componen el Sector Público Nacional, deberán intercambiar la información pública que produzcan, obtengan, obre en su poder o se encuentre bajo su control con cualquier otro organismo público que así se lo solicite.
Que el mencionado Decreto N° 1273 del 19 de Diciembre de 2016 facultó a la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar los protocolos de intercambio, pautas de interoperabilidad, normas complementarias, aclaratorias, técnicas y operativas necesarias para el cumplimiento de lo dispuesto en su Artículo 1ro.
Que el Decreto N° 894 del 1° de Noviembre de 2017, que aprobó el “Reglamento de Procedimientos Administrativos Decreto N° 1759/72 T.O. 2017”, estableció que las autoridades administrativas actuarán de acuerdo con los principios de sencillez y eficacia, procurando la simplificación de los trámites, y facilitando el acceso de los ciudadanos a la administración a través de procedimientos directos y simples por medios electrónicos.
Que, en ese orden de ideas, el Anexo I del citado Decreto N° 894 del 1° de Noviembre de 2017, que aprobó el “Reglamento de Procedimientos Administrativos Decreto N° 1759/72 T.O. 2017”, dispuso en su artículo 107 la eliminación de cargas al administrado, disponiendo que, en aquellos casos que para la sustanciación de un procedimiento administrativo sea necesaria la presentación de alguna información, dato, documento o certificado que deba ser emitido por otra entidad o jurisdicción del Sector Público Nacional, la entidad responsable del procedimiento lo solicitará directamente por comunicación oficial al organismo responsable de su producción y certificación, agregando que la solicitud del dato, información, documentación o certificado deberá expresar el motivo, el procedimiento en el cual se enmarca, y la norma que justifica su presentación.
Que en función de lo establecido en el artículo 2° del Decreto N° 1273 del 19 de Diciembre de 2016, la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM) aprobó las “Pautas Técnicas de Interoperabilidad” y los procedimientos aplicables al intercambio de información de carácter público entre los organismos comprendidos en el mencionado Decreto N° 1273/2016.
Que la mencionada Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM) estableció el efecto positivo del silencio de la Administración, favorable a la continuación del trámite, en el marco del Decreto N° 1273 del 19 de Diciembre de 2016, en aquellos casos en los cuales un organismo requiera información a otro, y el organismo productor de la información no contestare en un plazo de CINCO (5) días.
Que el aludido Decreto N° 1273 del 19 de Diciembre de 2016 instruyó a las entidades y jurisdicciones enumeradas en el artículo 8º de la Ley Nº 24.156 a celebrar convenios de colaboración recíproca con organismos provinciales, municipales, de la Ciudad Autónoma de Buenos Aires o entes públicos no estatales, para potenciar el deber de intercambio de información pública en el territorio nacional.
Que en esta instancia del proceso de modernización de la Administración Pública Nacional, resulta oportuno instrumentar un módulo de interoperabilidad que facilite a los organismos comprendidos en el Decreto N° 1273 del 19 de Diciembre de 2016 el intercambio de información en forma segura y directa, aliviando de cargas al administrado en los casos que un organismo requiera determinada información, dato, documento o certificado que deba ser emitido por otra entidad o jurisdicción del Sector Público Nacional.
Que este módulo de interoperabilidad actuará como nexo entre los sistemas informáticos y bases de datos de los organismos alcanzados por el Decreto N° 1273 del 19 de Diciembre de 2016, facilitando así el intercambio de información entre ellos, y posibilitando una respuesta rápida, segura, con información actualizada, y con valor jurídico, en un marco de seguridad y confianza.
Que resulta necesario a tal efecto implementar el módulo de Interoperabilidad (Interoper.ar) del sistema de Gestión Documental Electrónica – GDE, así como actualizar las “Pautas de Interoperabilidad” y los procedimientos aplicables para el intercambio de información entre los organismos comprendidos en el artículo 8 de la Ley N° 24.156, en reemplazo de los aspectos definidos en la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM).
Que, en consecuencia, resulta oportuno derogar la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM)
Que la DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA DIGITAL dependiente de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA y la SUBSECRETARÍA DE GESTIÓN ADMINISTRATIVA de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA se han expedido en los ámbitos de su competencia.
Que la presente medida se dicta en ejercicio de las facultades conferidas por el artículo 6° del Decreto N° 561/2016 y por el artículo 2° del Decreto N° 1273/16.
Por ello,
EL SECRETARIO DE MODERNIZACIÓN ADMINISTRATIVA DEL MINISTERIO DE MODERNIZACIÓN
RESUELVE:
ARTÍCULO 1°.- Apruébase la implementación del Módulo de Interoperabilidad (INTEROPER.AR) del sistema de Gestión Documental Electrónica – GDE como plataforma de intercambio seguro de la información pública que produzcan, obtengan, obre en su poder o se encuentre bajo el control de las entidades y jurisdicciones comprendidas en el Decreto N° 1273 de fecha 19 de Diciembre de 2016.
ARTÍCULO 2°.- El módulo INTEROPER.AR funciona como un nodo de intercambio entre los distintos sistemas de información y bases de datos de los organismos alcanzados por el Decreto N° 1273 de fecha 19 de Diciembre de 2016.
ARTÍCULO 3°.- La DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA DIGITAL dependiente de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA será responsable de:
a) Administrar el módulo INTEROPER.AR.
b) Ejercer el rol de autenticador de las aplicaciones de los organismos proveedores de los datos.
c) Establecer los procedimientos de alta y baja de los sistemas de información y bases de datos proveedores de datos.
d) Administrar el Directorio Interno de Servicios del módulo INTEROPER.AR.
ARTÍCULO 4°.- Las entidades y jurisdicciones responsables de los sistemas de información y bases de datos, ejercerán el rol de administración de sus propias aplicaciones, autorizarán las consultas a sus respectivas bases de datos en base a reglas propias de autorización y acceso a sus datos.
ARTÍCULO 5°.- Apruébase el documento “Descripción del Módulo de Interoperabilidad - INTEROPER.AR” que como Anexo I (IF-2018- 09344965- APN- DNSAYFD#MM) forma parte de la presente Resolución.
ARTÍCULO 6°.- Apruébanse las “Pautas Técnicas de Interoperabilidad de Sistemas” que como Anexo II (IF 2018-09344892-APN -SSGA#MM) forma parte de la presente Resolución.
ARTÍCULO 7°.- Establécese que, en el caso de información que no esté disponible en el módulo INTEROPER.AR, las entidades y jurisdicciones enumeradas en el artículo 8° de la Ley N° 24.156 que componen el Sector Público Nacional deberán intercambiar la información pública que produzcan, obtengan, obre en su poder o se encuentre bajo su control, con cualquier otro organismo público que así se lo solicite, de acuerdo a los siguientes procedimientos:
a) En los casos que la información requerida necesaria para la sustanciación de actuaciones no sea recurrente, el organismo solicitante deberá enviar una Nota a través del módulo Comunicaciones Oficiales (CCOO) del sistema de Gestión Documental Electrónica – GDE, para cada caso, detallando la información solicitada, la necesidad y la norma en la cual se fundamenta la solicitud.
b) En los casos que la información necesaria para la sustanciación de actuaciones sea recurrente, pero alguno de los dos Organismos no contara con la información requerida en un sistema informático, el organismo solicitante deberá enviar una nota mediante el módulo Comunicaciones Oficiales (CCOO) del sistema de Gestión Documental Electrónica – GDE, para cada caso, detallando la información solicitada, la necesidad y la norma en la cual se fundamenta la solicitud.
c) En los casos que la información necesaria para la sustanciación de actuaciones administrativas sea recurrente y ambos Organismos cuenten con la información requerida en un sistema informático, el organismo solicitante y el organismo productor de la información podrán realizar el intercambio automático de información mediante el módulo INTEROPER.AR, o bien mediante la interoperabilidad de sus sistemas, de acuerdo con las Pautas Técnicas de Interoperabilidad aprobadas en el Anexo II. A tal fin, el organismo requirente deberá solicitar al organismo productor de la información el establecimiento del mecanismo de consulta y respuesta automática, mediante el envío por única vez de una Nota a través del módulo Comunicaciones Oficiales (CCOO) del sistema de Gestión Documental Electrónica – GDE, mencionando la necesidad y la norma que fundamenta la solicitud de información.
ARTÍCULO 8°.- Establécese que en los casos que el intercambio de información no sea realizado a través del módulo INTEROPER.AR, el organismo productor de la información deberá responder en un plazo máximo de CINCO (5) días hábiles, salvo que estuviere expresamente establecido otro plazo.
ARTÍCULO 9°.- Establécese que en los casos en que la información solicitada sea pasible de ser respondida en forma afirmativa o negativa, y habiendo transcurrido el plazo de CINCO (5) días hábiles previsto en el artículo anterior sin respuesta del organismo productor de la información, el organismo solicitante considerará el silencio como favorable a la prosecución del trámite.
ARTÍCULO 10.- Derógase la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA (RESOL-2017-6-APN-SECMA#MM).
ARTÍCULO 11.- Comuníquese a la SINDICATURA GENERAL DE LA NACIÓN – SIGEN.
ARTÍCULO 12.- Comuníquese, publíquese, dése a la DIRECCIÓN NACIONAL DEL REGISTRO OFICIAL y archívese. — Eduardo Nicolás Martelli.
NOTA: El/los Anexo/s que integra/n este(a) Resolución se publican en la edición web del BORA -www.boletinoficial.gob.ar-.
e. 06/03/2018 N° 13250/18 v. 06/03/2018
(Nota Infoleg: Los anexos referenciados en la presente norma han sido extraídos de la edición web de Boletín Oficial.)
Anexo
Número: IF-2018-09344965-APN-DNSAYFD#MM
CIUDAD DE BUENOS AIRES
Viernes 2 de Marzo de 2018
Viernes 2 de Marzo de 2018
Referencia: Anexo I - Módulo de Interoperabilidad INTEROPER.AR
RESOLUCIÓN SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA
ANEXO I
DESCRIPCIÓN MÓDULO DE INTEROPERABILIDAD DECRETO N° 1273/2016
ANEXO I
DESCRIPCIÓN MÓDULO DE INTEROPERABILIDAD DECRETO N° 1273/2016
I.- Propósito
El presente documento tiene como objetivo definir las características del módulo de INTEROPERABILIDAD, en adelante INTEROPER.AR, administrado por la DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA DIGITAL, dependiente de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN
II.- Breve descripción de INTEROPER.AR
El presente documento describe el módulo INTEROPER.AR del Sistema de Gestión Documental Electrónica - GDE.
INTEROPER.AR es una capa de interoperabilidad que permite la interoperabilidad y el intercambio seguro de datos entre sistemas informáticos de gobierno.
Los organismos alcanzados por el Decreto N° 1273/2016 pueden utilizar el módulo INTEROPER.AR para facilitar, por ejemplo, la gestión de oficios judiciales, la tramitación interna que requiere datos o información disponible en otro organismo, o el suministro a terceros de datos o información en forma ágil, segura y con valor legal.
III.- Composición
1.- INTEROPER.AR se compone de:
1.1. El módulo de interoperabilidad que puede ser adoptado por todos los organismos que exponen sus servicios
1.2. Un esquema de autenticación, reglas y protocolos para facilitar las comunicaciones de forma directa y segura entre sistemas
1.3. Un Directorio de servicios
1.4. El Marco normativo
1.5. La Autoridad Central de administración del módulo.
1.6. Los sistemas informáticos o bases de datos distribuidas de las entidades y jurisdicciones proveedores de información.
2. - La autenticación entre sistemas informáticos o bases de datos que utilizan el modulo INTEROPER.AR está basada en estándares, es administrada por un organismo central pero la autorización y las bases de datos y los servicios permanecen distribuidos y autónomos, bajo la administración y exclusivo control de las entidades o jurisdicciones que los implementan.
3. - Conectarse a INTEROPER.AR permite a los organismos ahorrar costos y tiempos, porque acceden a una multiplicidad de servicios y bases de datos ofrecidos por otros organismos sin la dificultad de desarrollar soluciones para cada integración. Además le garantiza que todas las solicitudes de información que le llegan a través de INTEROPER.AR están debidamente autenticadas por un órgano central. La administración y autorización de quién accede a los datos propios del organismo se mantiene bajo exclusivo control de cada jurisdicción.
4. - INTEROPER.AR es un acelerador para el desarrollo de mejores soluciones al ciudadano, porque permite aplicaciones y servicios más inteligentes, que no preguntan lo que el Estado ya sabe y le acercan al ciudadano la información que requiere, sin imponer barreras innecesarias basadas en estructuras organizacionales.
5. - INTEROPER.AR provee a los organismos respuestas con total valor jurídico, emitidas por la autoridad competente para responder en función de las competencias sustantivas que posee y los datos que administra, ya que cada dato es provisto por el organismo que tiene competencia sobre él. Evita la duplicidad de datos, los padrones y bases de datos no actualizadas, las inconsistencias entre sistemas, brindando un servicio de respuesta automática, con datos actualizados.
6. - INTEROPER.AR garantiza el origen y el valor probatorio de cada solicitud y de cada respuesta, porque cada una tiene asociada una firma digital del sistema que la emite.
IV.- Funcionamiento
1.- Autenticación de los sistemas informáticos y bases de datos.
El módulo INTEROPER.AR brinda un servicio de autenticación de los sistemas informáticos y bases de datos que lo integran.
Este servicio de autenticación está centralizado en la autoridad que lo administra, la DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA DIGITAL, que gestiona las altas y bajas de los sistemas informáticos y bases de datos en el módulo INTEROPER.AR.
2.- Directorio interno de servicios.
El certificador a su vez mantiene un servicio dentro de INTEROPER.AR que es el directorio interno de servicios. Este directorio contiene toda la información necesaria para conectarse a los demás nodos de INTEROPER.AR - tanto información de uso, como documentación de APIs y endpoints, incluyendo también información de ubicación dentro de la red.
3. - Publicación de servicios.
Una vez que un sistema informático o base de datos está conectado a INTEROPER.AR puede publicar servicios usando los estándares de interoperabilidad vigentes y consumir los servicios de otros sistemas.
Cada invocación a un servicio se realiza punto a punto. Esto hace a la red robusta y tolerante a fallas y más segura, ya que no hay un solo punto de falla. Cada solicitud emitida o recibida es autenticada, cifrada y registrada para auditoría.
4. - Proveedores de servicios.
El modulo INTEROPER.AR facilita la interacción entre los organismos, ya que prevé su interoperabilidad, mediante un procedimiento sencillo y robusto desde el punto de vista de seguridad informática y jurídica.
Para integrar un sistema provisto por otro miembro de INTEROPER.AR, el organismo debe consultar el servicio de directorio. Con la información del directorio se realiza una conexión directa hacia el proveedor del servicio. Esta conexión puede ser por internet. El solicitante remite a través de INTEROPER.AR una solicitud de servicio con firma digital y se la envía al proveedor del servicio. El proveedor del servicio verifica la firma digital de la solicitud, verifica contra la Autoridad Central la validez de la firma y aplica reglas propias de autorización y acceso a sus datos. En caso de autorizar la transacción entonces devuelve una respuesta firmada digitalmente. Ambos participantes almacenan la evidencia de la operación.
V.- Marco Normativo.
El marco normativo que sustenta al módulo INTEROPER.AR está conformado por la Ley N° 25.506, los Decretos Nros. 434 del 1° de Marzo de 2016, 561 del 6 de Abril de 2016, 1273 del 19 de Diciembre de 2016, 894 del 1° de noviembre de 2017 y la Resolución N° 6 del 10 de Enero de 2017 de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN (RESOL-2017- 6-APN - SECMA#MM).
En efecto, la Ley N° 25.506 de Firma Digital, reconoció la eficacia jurídica del documento electrónico, la firma electrónica y la firma digital, y en su artículo 48 estableció que el Estado Nacional, dentro de las jurisdicciones y entidades comprendidas en el artículo 8° de la Ley N° 24.156, promoverá el uso masivo de la firma digital de tal forma que posibilite el trámite de los expedientes por vías simultáneas, búsquedas automáticas de la información y seguimiento y control por parte del interesado, propendiendo a la progresiva despapelización.
Por otra parte, el Decreto N° 434 del 1° de Marzo de 2016 aprobó el Plan de Modernización del Estado con el objetivo de alcanzar una Administración Pública al servicio del ciudadano en un marco de eficiencia, eficacia y calidad en la prestación de servicios, contemplando como segundo eje el desarrollo, mejora continua e integración de sistemas de gestión, planteando como objetivo incorporar nuevos sistemas y aprovechar iniciativas ya desarrolladas e implementadas que permitan encontrar soluciones transversales de administración integradas al Sistema de Gestión Documental y Expediente Electrónico, procurando cambiar el modelo de desarrollo sectorial, hacia uno homogéneo y cohesionado, para lo cual previó como actividad definir los estándares tecnológicos para promover la interoperabilidad de los sistemas y evitar que el ciudadano tenga que aportar información ya obrante en la Administración.
Adicionalmente, resulta consecuencia de lo dispuesto por el Decreto N° 561 del 6 de Abril de 2016, que aprobó la implementación del sistema de Gestión Documental Electrónica - GDE, como sistema integrado de caratulación, numeración, seguimiento y registración de movimientos de todas las actuaciones y expedientes del Sector Público Nacional, facultando en su artículo 6° a la SECRETARIA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar las normas complementarias, aclaratorias y operativas necesarias para la implementación de dicho sistema y el funcionamiento de los sistemas informáticos de gestión documental.
Pero fundamentalmente, el módulo INTEROPER.AR es consecuencia de lo establecido en el Decreto N° 1273 del 19 de Diciembre de 2016, que dispuso la obligación de las entidades y jurisdicciones enumeradas en el artículo 8 de la Ley N° 24.156 que componen el Sector Público Nacional a intercambiar la información pública que produzcan, obtengan, obre en su poder o se encuentre bajo su control con cualquier otro organismo público que así se lo solicite.
El mencionado Decreto N° 1273 del 19 de Diciembre de 2016 facultó a la SECRETARIA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar los protocolos de intercambio, pautas de interoperabilidad, normas complementarias, aclaratorias, técnicas y operativas necesarias para el cumplimiento de lo dispuesto en su artículo 1°.
En tal sentido, la SECRETARIA DE MODERNIZACIÓN ADMINISTRATIVA emitió la Resolución N° 6 de fecha 10 de Enero de 2017, en la cual estableció, por una parte, las 'Pautas Técnicas de Interoperabilidad' y además, los procedimientos de intercambio de información, estableciendo el efecto positivo del silencio de la administración.
Efectivamente, la mencionada Resolución N° 6/2017 estableció que, en el marco del Decreto N° 1273 del 19 de Diciembre de 2016, cuando un organismo requiera información a otro, y el organismo productor de la información no contestare en un plazo de CINCO (5) días, se le reconocerá al silencio sentido positivo.
Complementariamente, el Decreto N° 894 del 1° de Noviembre de 2017, que aprobó el 'Reglamento de Procedimientos Administrativos Decreto N° 1759/72 T.O. 2017', estableció que las autoridades administrativas actuarán de acuerdo con los principios de sencillez y eficacia, procurando la simplificación de los trámites, y facilitando el acceso de los ciudadanos a la administración a través de procedimientos directos y simples por medios electrónicos.
En ese orden de ideas, el Anexo I del citado Decreto N° 894 del 1° de Noviembre de 2017, que aprobó el 'Reglamento de Procedimientos Administrativos Decreto N° 1759/72 T.O. 2017', dispuso en su artículo 107 la eliminación de cargas al administrado, disponiendo que, en aquellos casos que para la sustanciación de un procedimiento administrativo sea necesaria la presentación de alguna información, dato, documento o certificado que deba ser emitido por otra entidad o jurisdicción del Sector Público Nacional, la entidad responsable del procedimiento lo solicitará directamente por comunicación oficial al organismo responsable de su producción y certificación. La solicitud del dato, información, documentación o certificado deberá expresar el motivo, el procedimiento en el cual se enmarca, y la norma que justifica su presentación.
En síntesis, en esta instancia del proceso de modernización de la Administración Pública Nacional, resulta oportuno instrumentar una medida que simplifique los trámites administrativos, eliminando de cargas al administrado en los casos que un organismo requiera determinada información, dato, documento o certificado que deba ser emitido por otra entidad o jurisdicción del Sector Público Nacional.
Ello así, y a los efectos de lograr una modernización efectiva de la gestión administrativa del Estado, es esencial contar con una herramienta de interoperabilidad que permita el intercambio directo entre organismos de documentación y datos que actualmente se le solicitan al particular, facilitando de manera permanente el acceso, consulta y transferencia de información pública para lograr la interconexión y operación simultánea.
Anexo
Número: IF-2018-09344892-APN-SSGA#MM
CIUDAD DE BUENOS AIRES
Viernes 2 de Marzo de 2018
Viernes 2 de Marzo de 2018
Referencia: Anexo II - Pautas Técnicas de Interoperabilidad de Sistemas
RESOLUCIÓN SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA
ANEXO II
'Pautas Técnicas de Interoperabilidad de Sistemas'
ANEXO II
'Pautas Técnicas de Interoperabilidad de Sistemas'
I. - Introducción
Las presentes 'Pautas Técnicas de Interoperabilidad de Sistemas' tienen por objeto brindar un marco de intercambio de información entre las entidades y jurisdicciones que integran el Sector Público Nacional, en el marco del Decreto Nro. 1273/2016.
Las interfaces de programación de aplicaciones (APIs) exponen las funciones internas de un sistema al mundo exterior. Esto permite que los sistemas compartan información sin requerir que los desarrolladores tengan que compartir el código de las aplicaciones, ni entender las complejidades internas de cada sistema.
II. - Alcances
A los fines de facilitar el intercambio de información entre las entidades y jurisdicciones que componen el Sector Público Nacional, de acuerdo a lo dispuesto en el Decreto Nro. 1273 del 19 de diciembre de 2016, se establecen las siguientes Pautas de Interoperabilidad. Las entidades y jurisdicciones detalladas en el artículo 8 de la Ley Nro. 24.156 deberán intercambiar la información desarrollando APIs siguiendo los siguientes lineamientos.
Estas 'Pautas Técnicas de Interoperabilidad de Sistemas' son de aplicación para todas las entidades y jurisdicciones que integran la Administración Pública Nacional o Entidades de derecho Público vinculadas o dependientes de aquélla (en adelante, organizaciones) que participan en el intercambio de asientos registrales, ya sea para la prestación de servicios directos a los ciudadanos, como de cara al intercambio de información con otros órganos.
III. - Arquitectura REST
Las 'Pautas Técnicas de Interoperabilidad de Sistemas' se basan en la arquitectura REST. Dicha arquitectura especifica un conjunto de principios de arquitectura de Software que definen la interacción entre distintos componentes dentro de un sistema de hipermedia distribuido. En particular, se implementará arquitectura REST sobre el protocolo HTTP.
Los principios generales a los que deberán ajustarse son:
- Arquitectura cliente-servidor: Un cliente realiza peticiones a un servidor, el cual devuelve respuestas.
- Stateless: Cada petición que se realiza será independiente de la siguiente.
- Cacheable: Una vez realizada la primera petición, el resto podrán ser obtenidas del cache en caso de no haber sufrido cambios.
- Sistema por capas: Para toda petición originada de un cliente al servicio no será distinguible si está siendo dirigida directo al servidor o a un sistema de chache o balanceador.
- Identificación del recurso: Se deberá indicar a través de una URI, la misma debe cumplir con el RFC 3986.
- Operaciones uniformes: Los métodos serán los especificados en HTTP (GET, PUT, POST, DELETE) provistos en el RFC 2616.
- Formato o representación del recurso: El tipo de contenido deberá ser del tipo JSON, el mismo se encuentra definido en el RFC 7159 https://tools.ietf.org/html/rfc7159
IV.- Pautas en el diseño
- Se debe crear una URI para cada recurso. Estos deben ser sustantivos, no verbos.
No se debe utilizar: http://www.ejemplo.com.ar/entidades/obtenerentidad?id=001
Se debe utilizar: http://www.ejemplo.com.ar/entidades/001
Use los verbos HTTP (GET, POST, PUT, DELETE) para funcionar en las colecciones y elementos.
Ponga el número de versión en la URL, por ejemplo: http://ejemplo.gob.ar/vL0/path/to/resource
Especificar campos opcionales como una lista separada por coma.
Para indicar el formato de respuesta utilizar el campo content-type del header siendo por defecto el formato JSON. Por ejemplo: XML: Content-Type: application/xml JSON: Content-Type: application/json; charset=utf-8
El formato DEBE ser del tipo: api/v2.0/resource/{id}
Utilizar sub recursos para indicar relaciones.
Si un recurso está relacionado a otro, se deberá representar como un sub recurso del mismo. Ejemplo: /organismos/{id del organismo}/empleados/{id_empleado}
No obstante es válido y muchas veces necesario que exista /empleados como top-level uri dentro de la API.
En el caso de que una representación incluya una lista de objetos relacionados debe incluir links a las URI de cada objeto.
De otra forma sólo se puede navegar el árbol de relación teniendo información externa a los resultados que indique dónde ir a buscar cada recurso.
Una URi que apunta a un sub-recurso (ej, /organismos/{id_organismo}/empleados/ 123 puede devolver la representación del sub-recurso o simplemente utilizar un redirect http para indicar el top-level que lo devuelve (ej HTTP 307 moved temporarily)
- Categorizar los recursos de acuerdo a las acciones que los clientes pueden realizar sobre los mismos, por ejemplo una representación del recurso o modificación.
Para las representaciones, se deben utilizar el verbo HTTP GET.
Para las modificaciones, se deben utilizar los verbos HTTP POST, PUT y/o DELETE.
- Los request GET no deben tener efectos sobre el recurso al que apuntan. Sólo deben devolver su representación. Por lo tanto, invocar al recurso no debería tener como resultado modificarlo.
- Manejo de errores y respuestas usando códigos HTTP estándar
Usar los códigos de estado HTTP para indicar el resultado de las invocaciones a la API. Los más importantes son los siguientes:
- 200 ,201,204
- 304, 307
- 400,401,403,404,422
- 500
Las respuestas de errores DEBEN incluir los códigos de estados HTTP, mensaje para el desarrollador, mensaje para el usuario final, código de error interno, enlaces con documentación al respecto. Por ejemplo:
{
'status' : 400,
'developerMessage' : 'Descripción clara del problema. Sugerencias de cómo resolver el problema.', 'userMessage' : 'Este es el mensaje para el usuario final.', 'errorCode' : '[444444|exceptionName]',
'moreInfo' : 'http://www.ejemplo.gob.ar/developer/path/to/help/for/444444,
http://drupal.org/node/444444',
}
- Mantener en minúsculas la URI.
- Usar UTF-8 y aceptar caracteres 'especiales' como comillas, tildes, símbolos.
- Esconder las extensiones de las tecnologías utilizadas (.php, .asp, .jsp, etc).
- Se deberá utilizar como encoding UTF8, y deberá ser informado en la cabecera (Conten-tType: application/json; charset=utf-8)
- Se deberán utilizar fechas según ISO 8601 en UTC Para solo fechas, el formato debe ser 2016-01-27.
Para fechas completas, el formato debe ser 2016-01-27T10:00:00Z.
- Una API que retorna JSON DEBE usar el content type adecuado al tipo de datos y encoding que devuelve.
El recomendado es:
Content-Type: application/json; charset=utf-8
Ejemplos válidos de URLs Lista de artículos:
GET http://www.ejemplo.gob/api/vL0/articulos
Filtrando con query string:
GET http://www.ejemplo.gob/api/v1.0/articulos?year=2016&sort=desc
Un artículo en formato JSON:
GET http://www.ejemplo.gob/api/vL0/articulos/1234
Todos los comentarios de un artículo en particular:
GET http://www.ejemplo.gob/api/vL0/articulos/1234/comentarios
Especificar campos opcionales en una lista separada por coma:
GET http://www.ejemplo.gob/api/v1.0/articulos/1234?fields=title,body
Agregar un comentario a un artículo específico:
POST http://ejemplo.gob/api/vL0/articulos/1234/comentarios
Ejemplos NO válidos de URLs:
Sustantivos singulares: http://www.ejemplo.gob/api/vL1/articulo http://www.ejemplo.gob/api/vL1/articulo/1234
Verbo en la URL: http://www.ejemplo.gob/api/vL1/articulo/1234/create
Filtro fuera del query string http://www.ejemplo.gob/api/vL1/articulos/2016/desc
V.- Verbos HTTP
Los verbos HTTP, o métodos, se deben utilizar en el cumplimiento de sus definiciones de la norma HTTP/1.1 .
Este es un ejemplo de cómo deben ser los verbos HTTP para crear, leer, actualizar y eliminar las operaciones en un contexto particular:
VI.- Soporte JSON
- Las respuestas DEBEN ser objetos JSON (no arrays). Usar un array para retornar resultados limita la capacidad de incluir metadata sobre resultados, y limita la capacidad de las API's para agregar top-level keys en el futuro.
- Se puede incluir un parámetro especial para devolver los datos en otros formatos como XML, CSV u otro.
GET http://www.ejemplo.gob/api/v1.0/articulos?format=csv
GET http://www.ejemplo.gob/api/vL0/articulos.csv
- No usar claves impredecibles. Realizar el parsing de una respuesta JSON donde las claves son impredecibles es difícil.
- Usa guión_bajo para las claves. Diferentes lenguajes usan diferentes convenciones. JSON usa guión_bajo, no camelCase.
Más info en json.org
VII.- Documentación
Para documentar los Servicios WEB REST se debe incluir una introducción funcional que describa qué hace la API, y para cada servicio lo siguiente:
Nombre
URI
Ejemplo de uso incluyendo invocación con curl y la respuesta del ejemplo.
Descripción de los parámetros obligatorios y opcionales
Valores por default Códigos de error.
Ejemplo de documentación
Listar Reparticiones Obtiene la lista de reparticiones
Uso: curl 'http://ejemplo.gob.ar/api/v1/reparticiones' -H 'Authorization: tokendeautenticacion'
El comando anterior devuelve una respuesta JSON como :
{
items: [
{
'id': 1,
'name': 'reparticionl',
'propiedad': 'valor'
},
{
'id': 2,
'name': 'reparticion2',
'propiedad': 'valor'
},
]
}
Este endpoint devuelve las reparticiones según los parámetros de filtro HTTP Request
GET http://example.com/api/kittens
Parámetros del request: Parametro Default Descripción
incluir_externos false Si está en true, la respuesta incluye reparticiones externas.
activas true Si está en false, la respuesta incuirá reparticiones que no están activan en el sistema
Nota — Este servicio no requiere autenticación.
También se admitirá utilizar herramientas de documentación como: SWAGGER MkDocs Aglio
Documentar los ejemplos de la forma mas genérica posible, contemplando mas de un lenguaje de ser posible (por ejemplo Python y Java)
VIII. - Seguridad
Con el objetivo de ofrecer escalabilidad, y generar servicios WEB stateless (sin estado) y aptos para aplicaciones móviles, se deberá implementar seguridad a través de los siguientes lineamientos:
Autenticación Basada en Tokens
Se implementará a partir de JSON WEB TOKEN (JWT) explicado en el RFC 7519 utilizando para asegurarlo los estándares JWS y JWE (RFC 7515 y 7516) utilizándo como mínimo el algoritmo HMAC
Protocolo de comunicación segura
La implementación de los servicios WEB RESTFul deberá ser implementada en https para ofrecer encriptación.
IX. - Versiones
Nunca libere la versión de una API sin su número de versión.
Los números de versión deben abarcar dos niveles de versión: x.x
Las versiones DEBEN ser enteros, no decimales, con el prefijo 'v'.
Dar soporte al menos una versión anterior a la actual.
Ejemplos: Válido: v1.0, v2.1, v3.5 No válido: v-1.1, v1.2.5, 1.3.3
X.- Casos particulares
Para algunos tipos de intercambio de información deben tenerse especial cuidado en la arquitectura de las APIs para que sean efectivas. Algunos casos particulares que pueden requerir complementar REST con otros protocolos son:
a) Transferencias Masivas. Cuando el cliente requiera tener una copia propia de un set de datos muy grande por motivos válidos (implementar un motor de búsqueda, hacer procesos de inteligencia de negocio, etc). Si la API no puede transmitir la información de forma eficiente o escalable (para el cliente como para el servidor) puede ser necesario implementar otros métodos.
b) Notificaciones inmediatas. Las APIs REST funcionan a pedido del cliente. En el caso de que el cliente deba tener las últimas modificaciones o novedades de forma inmediata se pueden implementar métodos tipo callback (si el servidor lo permite) o tecnologías de streaming de datos, publisher subscriber, etc. De ser posible deben mantenerse sobre HTTP (utilizando websockets, Server Sent Events,etc)
c) Transacciones costosas. Las transacciones que disparan operaciones muy costosas deben implementarse de forma asincrona, evitando bloquear a los sistemas que las ejecutan.