argob / estandares

Estándares de Servicios Digitales

Principios y Estándares de Servicios Digitales

Formas de trabajar de la Dirección Nacional de Servicios Digitales de la República Argentina.

Principios

• Principios de Servicios Digitales

Servicios, Diseño de Productos y Contenido

• Estándares de Servicios
• Estándares de Atención al Público
• Estándares de Diseño de UX e Identidad Visual
• Guía de Diseño de Interfaces Conversacionales (Chatbots)
• Guía de Contenido Web
• Guía de revisión de accesibilidad de sitios webs en computadoras de escritorio

Desarrollo e Infraestructura

• Estándares de Sitios Web
• Estándares de Aplicaciones Móviles
• Estándares de APIs
• Información de trámites provinciales
• Implementación de Google Tag Manager

---

Nos inspiramos en GOV.UK Design Principles y U.S. Digital Services Playbook.

estandares's Issues

Pasar a wiki

Hola! Creo que toda esta documentación es fantástica, pero subirla como un montón de archivos md entrelazados es forzar un poco la función de un repo. Si se pasara esta documentación a la wiki del repo, se aprovecharía la funcionalidad que viene con las wikis, como un editor de texto más avanzado e integrado a GitHub. ¿Qué les parece? ¿Hay alguna razón para no hacerlo?

Reemplazar PUT por PATCH

Hola,
deberían considerar reemplazar el verbo PUT por PATCH.

El verbo PUT debe ser utilizado para el reemplazo total de un documento y el verbo PATCH para modificaciones parciales.

fuente

Page Not Found

Hola,

No se encuentra disponible el siguiente recurso en la documentación de estandares.

https://pages.18f.gov/fbopen/apidocs/

Considerar usar Semantic Versioning para la numeración de versiones

Los nuevos estándares web dicen:

Control de versiones: deberán estar etiquetadas con correspondiente nombre con el formato "vx.x.x".

Sería bueno considerar usar versionado semántico para las mismas.

JSONP

Considerar soporte JSONP como complemento a CORS.
Se sabe que JSONP es más un "hack" que una feature, pero algunos browsers tienen problemas aún: https://blogs.msdn.microsoft.com/ieinternals/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds/
El impacto en los sistemas es mínimo y suma.
Considerar que la conf de CORS debe aplicar sólo a los entrypoints API.
Para revisar: Guía de construcción de APIs del gobierno de Chile: http://kitdigital.gob.cl/recursos-de-desarrollo/guia-construccion-apis/

Soporte de método HTTP PATCH para actualizaciones parciales

Actualmente utilizamos el método PATCH (rfc5789) para permitir realizar actualizaciones parciales de recursos.

Es decir, mientras que PUT requiere que se envíe el recurso completo, PATCH permite que se envíen solo los aquellos campos o partes del recurso que se quiere actualizar. Esto representa una gran ventaja para recursos de granularidad gruesa (como recomienda el estilo ReST) ya que permite evitar el envío de todo el documento cuando se desea actualizar solo una pequeña porción.

Aún en un ejemplo simplificado se puede apreciar el beneficio de poder enviar:

PATCH /persona/23535

{"edad":25}

Comparado con:

PUT /persona/23535

{
  "nombre": "pedro josé",
  "edad":20,
  "domicilio": {
    "calle":"blabla",
    "numero":3132,
    "piso":3,
    "departamento":"x",
    "localidad":"xxx"
  },
  "identidad": [
    {
    "tipo":"xxx",
    "identificador":"23423424",
    "vigencia": {
      "desde":"20100101",
      "hasta":"20181231"
    }
    ]
  }
}

Si lo único que se desea es actualizar la edad.

Semánticamente, en el caso de PATCH, se actualizará solo el campo "edad" con el nuevo valor, dejando todo lo demás en su estado preexistente en el recurso.

Si fuera necesario, se pueden utilizar los headers estándar If-Match/Etag para implementar optimistic locking.

Si bien en este proyecto ya se ha tocado el tema (#10, #3), no encuentro una decisión al respecto y creo que sería muy valiosa su incorporación.

DNRPA CAIDO ??? Error o apropósito ???

Perdon capaz no es el lugar Alguien sabe por que esta caido todo el DNRPA ??? sera apropósito ???

ya hace 3 dias que esta todo caido

REST verbs

Dentro de la tabla que especifica los verbos de HTTP a usar

HTTP METHOD	POST	GET	PUT	DELETE
CRUD OP	CREATE	READ	UPDATE	DELETE
/articulos	Crea nuevo artículo	Lista de artículos	Actualiza un artículo	Elimina todos los artículos
/articulos/1234	Error	Muestra el artículo 1234	Si existe, actualiza el artículo; sino, devuelve error.	Borra 1234

hay dos cosas que me llaman la atención:

1. Cómo realizar un PUT desde /articulos sin especificar a qué recurso nos estamos refiriendo
2. No está especificado el verbo PATCH que es de mucha utilidad si se quiere cambiar parte de un recurso. La semántica de PUT es tomar el recurso que llega en el request y cambiarlo por el existente si existe y sino crearlo. En cambio PATCH describe los cambios a realizar en el recurso parcialmente. No se si es necesario agregar el verbo pero tal vez resulta un poco confusa la definición de PUT ya que en la descripción de la sección dice

Los verbos HTTP, o métodos, se deben utilizar en el cumplimiento de sus definiciones de la norma 1.1 / HTTP (...)