Diferencias

Muestra las diferencias entre dos versiones de la página.

--- unidades:10_servidor:01_rest [2014/08/30 12:55] – [El formato de los datos] admin
+++ unidades:10_servidor:01_rest [2014/10/13 09:32] (actual) – [Referencias] admin
@@ Línea 21: / Línea 21: @@
 Los datos que se envían es una petición HTTP son:
   * La URI del recurso que se pide.
+  * El método HTTP
   * Las cabeceras HTTP. Hay gran cantidad de cabeceras pero su formato es siempre el nombre de la cabecera y su valor.
   * El cuerpo de la petición con los datos del usuario. Por ejemplo datos en formato JSON o datos en formato XML.
@@ Línea 42: / Línea 43: @@
   * El formato de los datos
   * El estado de la aplicación
-  * La paginación
+  * Cache
+  * Etc.
 ===== Las operaciones a realizar =====
@@ Línea 101: / Línea 103: @@
 Una posible modificación que vi en un proyecto real consistía en hacer que el update y el insert no retornaran el objeto completo actualizado o insertado. Y no lo retornaban para ahorra tiempo y ancho de banda. Solo se retornaba en id del objeto recién insertado. Luego si hacía falta todos los datos , cosa que no solía necesitarse, se podían obtener con una llamada a ''GET'' extra.
 </note>
 ===== Tratamiendo de errores =====
@@ Línea 181: / Línea 185: @@
 Aunque esto es la teoría , yo personalmente si que guardo en la sesión el usuario que ha entrado en el sistema aunque se podría crear una solución **similar**  sin necesidad de guardar en el servidor nada usando [[https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/|Token-Based Authentication]].
+===== Cache =====
+Al ser una petición REST como cualquier otra petición a una página web deberíamos tener en cuenta que las peticiones se pueden cachear en el navegador o en cualquier otro punto de la red. Por ello en general es adecuado indicar desde el servidor si la respuesta puede ser o no cacheada.
+===== Otras características =====
+Siguiente HTTP podríamos ver mas cosas como por ejemplo como hacer la paginación, como retornar solo ciertos campos , etc. Pero no los vamos a ver en este curso.
+====== Referencias ======
+  * [[http://en.wikipedia.org/wiki/Representational_state_transfer|Wikipedia > REST]]
+  * [[http://martinfowler.com/articles/richardsonMaturityModel.html|Richardson Maturity Model]]
+  * [[https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/|Cookies vs Tokens. Getting auth right with Angular.JS]]
+  * [[http://stackoverflow.com/questions/2001773/understanding-rest-verbs-error-codes-and-authentication|Understanding REST: Verbs, error codes, and authentication]]: Clásica pregunta sobre REST en stackoverflow
+  * [[http://java.dzone.com/articles/restful-standard-resolved|RESTful Standard Resolved!]]: Resumen del formato de las URL en REST
+  * [[http://rest.elkstein.org/|Learn REST: A Tutorial]]: Tutorial en inglés sobre REST
+  * [[http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven|REST APIs must be hypertext-driven]]: Las API REST deben tener las URL a los recursos.
+  * [[http://blog.2partsmagic.com/restful-uri-design/|REST-ful URI design]]: Como diseñar un buen API REST
+  * [[http://elbauldelprogramador.com/buenas-practicas-para-el-diseno-de-una-api-restful-pragmatica/|Buenas prácticas para el diseño de una API RESTful pragmática]]