Diferencias

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

--- unidades:10_servidor:01_rest [2014/08/30 12:35]
admin [Tratamiendo de errores]
+++ unidades:10_servidor:01_rest [2014/10/13 09:32] (actual)
admin [Referencias]
@@ 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 160: / Línea 164: @@
 Mas información sobre esta clase la puedes encontrar en mi curso de hibernate en [[http://cursohibernate.es/doku.php?id=unidades:07_arquitectura:02_excepciones&#el_codigo_de_bussinessexception|El código de BussinessException]]
+===== El formato de los datos =====
+Como ya dijimos al ver el formato de las URI, para indicar el formato en el que queremos que nos retornen los datos hay que usar la cabecera ''Accept''. Desde Angular no tenemos que preocuparnos por poner esta cabera ya que lo hace automáticamente para pedir los datos en formato JSON.
+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 ''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:
+  * En la petición:
+    * ''Accept'' : Para indicar el formato de los datos que queremos que nos retorne el servidor
+    * ''ContentType'' : Para indicar el formato de los datos que le estamos enviando.
+  * En la respuesta:
+    * ''ContentType'' : Para indicar el formato de los datos que se está devolviendo.
+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]]

unidades/10_servidor/01_rest.1409394904.txt.gz · Última modificación: 2014/08/30 12:35 por admin

Ir hasta arriba