More on this book
Kindle Notes & Highlights
retrasamos los...
This highlight has been truncated due to consecutive passage length restrictions.
pensar en cómo podríamos resolver esos mismos problemas cambiando el foco.
"Si quieres resultados distintos, no hagas siempre lo mismo".
Podemos ser muy creativos definiendo una arquitectura de clases con un diseño magnifico, que sea muy académico, organizado, ordenado e incluso elegante. Pero si al hacer unas pruebas de prestaciones no cumplimos los requisitos del producto por haber demasiadas capas de clases o no estar lo suficientemente optimizado de cara al rendimiento que debe ofrecer, no nos sirve de nada.
Hay que tener en cuenta el contexto y contorno de cada componente a desarrollar dentro del producto y negocio en el que se encuentra así como la naturaleza de los datos que se manejan.
especial hincapié en el chequeo de la calidad de software y de pruebas de prestaciones.
Por este motivo se entiende que los programadores rehúyen las reuniones, evitan las interrupciones y necesitan mucha concentración para su trabajo. La pérdida de esa concentración implica perder y olvidar cosas que tienen en la cabeza y que pueden tener impacto en la implementación
REST (Representational State Transfer1) no es un protocolo, sino unos principios de arquitectura, un estilo y unos patrones de diseño para la descripción de interfaces web.
Los conceptos básicos de REST son los siguientes:
Lo principal son los recursos.
Un recurso es igual a una URI. La URI indica donde...
This highlight has been truncated due to consecutive passage length restrictions.
una URI puede identificar a dos tipos de recursos:
una colección o un recurso individual. Una colección es simplemente una agrupación de recursos del mismo tipo.
Las colecciones se deben nombrar en plural y con nom...
This highlight has been truncated due to consecutive passage length restrictions.
Los recursos individuales tienen su propio identificador,
los métodos HTTP sirven para realizar operaciones sobre las colecciones y recursos.
POST para Crear, GET para Obtener, PUT para actualizar y DELETE para borrar.
Manejo de errores,
400 Bad Request si la petición es sintácticamente invalida, 401 Unauthorized para problemas de autenticación, 403 Forbidden para problemas de autorización o limitación por políticas, 404 Not Found si se intenta acceder a un recurso que no existe (o que se quiere ocultar), 5xx cuando hay algún problema en el servidor.
es muy útil incluir un body HTTP con un formato definido que incluya por ejemplo el código del error (útil para la máquina), un texto descriptivo (para el humano) y una URL donde obtener más información del error.
Filtrados y búsquedas, útiles para obtener recursos de una colección que cumplan ciertos criterios y para obtener solo los atributos de los recursos que se requieran.
se consiguen a través de query strings o query parameters
query ?fields=param1,param2,param3
query: ?crit1=2&crit2=3,4
Para paginar, usando dos query parameters
offset se indica el desplazamiento
limit se indica el núm...
This highlight has been truncated due to consecutive passage length restrictions.
Un aspecto fundamental para el mantenimiento y evolución de un A...
This highlight has been truncated due to consecutive passage length restrictions.
incluir el número de versión del API en la propia URL, justo despué...
This highlight has been truncated due to consecutive passage length restrictions.
se evoluciona la versión en la URL, solo cuando se haga un cambio ...
This highlight has been truncated due to consecutive passage length restrictions.
¿cómo indicar la URL de un recurso cuando éste es creado?
una cabecera HTTP Location
incluir en la respuesta la representación del recurso creado, que incluirá entre sus atributos el identificador del recurso.
devolver solo el identificador del recurso en vez de su representación completa.
Formatos y representaciones.
formato que mejor encaja en un API REST es JSON3,
API REST representando los recursos en XML4, y
usar URLs sencillas y entendibles es fundamental.
https://host:puerto/nombre/{version}/coleccion/{Id}?queries
Uso pragmático de REST: Situaciones y soluciones Las bases de REST son sencillas y claras, pero no siempre es obvio aplicarlas.
Restringir y elegir. No se debe permitir todo
No hay que permitir CRUD totalmente, si alguna operación no tiene sentido en tu API, simplemente restríngela.
Algunos escenarios no encajan como recursos, ¿qué hacer?
Si aun así sigue alguno de los escenarios sin encajar como un recurso, diferéncialo claramente. ¿Cómo? Pon un verbo en tu URL e indica lo que hace esa URL.
Crear un recurso 'eligiendo su identificador' frente a 'el servidor elige el identificador':
usar PUT solo cuando se pretende sustituir un recurso enviando su nueva versión de forma completa.
Con POST se deberían hacer actualizaciones parciales:
DELETE completa las actualizaciones parciales:
Los atajos de usabilidad:

