Diferencias

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

--- unidades:10_servidor:01_rest [2014/08/30 12:47] – [Tratamiendo de errores] 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 165: / Línea 169: @@
 Por otro lado cuando insertamos o actualizamos , estamos enviando datos en formato JSON, ¿Como le decimos al servidor que son en formato JSON? Usando la cabecera ''Content-Type: application/json''. Tampoco debemos preocuparnos en ponerla ya que AngularJS también lo hace por defecto.
-Al retornarnos el servidor los datos también incluirá en la respuesta otra cabecera ''contentType'' para indicar el formato de los datos que ha retornado.
+Al retornarnos el servidor los datos también incluirá en la respuesta otra cabecera ''Content-Type'' para indicar el formato de los datos que ha retornado.
 Vamos ahora a resumir las cabeceras que hay al hacer una petición y recibir la respuesta:
@@ Línea 174: / Línea 178: @@
     * ''ContentType'' : Para indicar el formato de los datos que se está devolviendo.
-en la petición no tendremos que preocuparnos de ponerlo yaque AngularJS ya lo hace pero en la respuesta nosotros deberemos indicar el ''ContentType''
+Como ya hemos dicho, en la petición no tendremos que preocuparnos de poner estas cabeceras ya que AngularJS ya lo hace pero en la respuesta nosotros deberemos desde Java indicar el ''Content-Type''
+===== El estado de la aplicación =====
+El tema del estado de la aplicación en el servidor es muy sencillo de tratar en REST. Simplemente nunca hay estado en el servidor para cada cliente. Cada petición debe ser independiente de las demas y nunca guardar nada en la sesión del servidor.
+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]]