Herramientas de usuario
code:rest
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa | ||
|
code:rest [2010/07/17 09:48] alfred |
code:rest [2020/05/09 09:25] (actual) |
||
|---|---|---|---|
| Línea 39: | Línea 39: | ||
| Mientras que en otro tipo de web services se pone énfasis en los verbos (''getUser(data)'', ''updateUser(data)''...) en REST se pone énfasis en los nombres (''User {data}''). Un recurso tendría su propio identificador, como por ejemplo __<nowiki>http://www.example.org/locations/us/ny/new_york_city</nowiki>__ donde, si se accede a partir del método GET, podrían haber los datos de la ciudad de New York, además puede ser sencillamente cacheado, copiado y guardado como marcador. | Mientras que en otro tipo de web services se pone énfasis en los verbos (''getUser(data)'', ''updateUser(data)''...) en REST se pone énfasis en los nombres (''User {data}''). Un recurso tendría su propio identificador, como por ejemplo __<nowiki>http://www.example.org/locations/us/ny/new_york_city</nowiki>__ donde, si se accede a partir del método GET, podrían haber los datos de la ciudad de New York, además puede ser sencillamente cacheado, copiado y guardado como marcador. | ||
| + | |||
| + | |||
| ===== Interface uniforme ===== | ===== Interface uniforme ===== | ||
| + | El protocolo HTTP es un protocolo cliente-servidor que se implementa a nivel de aplicación y define operaciones sobre los recursos del servidor (como GET, POST, PUT y DELETE), esto evita al desarrollador que lo utilice incorrectamente (es decir que siga la regla de ''Interface Uniforme'') tener que inventar nuevos métodos (como ''getClients'' o ''updateStops''). | ||
| + | |||
| + | ==== Visibilidad ==== | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ==== Uso de métodos HTTP ==== | ||
| + | |||
| + | ===== Seguridad en REST ===== | ||
| + | |||
| + | ===== Desarrollo erróneo ===== | ||
| + | |||
| + | |||
| + | ==== Errores comunes ==== | ||
| + | * **Fuente**: [[http://www.prescod.net/rest/mistakes/]] | ||
| + | Los errores que se llevan a cabo en el desarrollo de servicios REST son: | ||
| + | - No seguir los estándards HTTP. | ||
| + | - Utilizar POST para otros fines que no sea la creación de un nuevo elemento. | ||
| + | - Depender de la estructura del servidor. Las URIs deberían ser configurables. | ||
| + | - Utilizar acciones en las URIs. Por ejemplo "someuri?action=delete" es erróneo. | ||
| + | - Usar sesiones. Las aplicaciones son consumidores de recursos, no servicios. | ||
| + | - No utilizar las URIs correctamente. Para acceder a un recurso haríamos "someuri/resource/322" o utilizaríamos RDF. | ||
| + | - Preocuparse por el protocolo. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ==== AntiPatrones REST ==== | ||
| + | * **Fuente**: [[http://www.infoq.com/articles/rest-anti-patterns]] | ||
| + | === Utilizar con exceso GET === | ||
| + | GET debe de traer la representación de un recurso identificado por una URI. \\ | ||
| + | Una URI como la siguiente sería incorrecta: ''<nowiki>http://example.com/some-api?method=deleteCustomer&id=1234</nowiki>'', es posible que sea más fácil de desarrollar y testear, pero en este caso no se está utilizando la URI como un identificador, además el link no puede ser guardado, puede que un robot de búsqueda lo ejecute sin querer... \\ | ||
| + | Un GET no debe modificar. | ||
| + | |||
| + | === Utilizar con exceso POST === | ||
| + | Similar al anterior solo que con el método POST. \\ | ||
| + | GET es para leer, POST para modificar. | ||
| + | |||
| + | === Ignorar la caché === | ||
| + | Utilizar una cabecera como ''Cache-control: no-cache'' evitaría que el navegador insertase en su caché el contenido. A veces esto puede ser útil pero a menudo se le puede sacar partido a la caché del cliente, por ejemplo si un recurso se actualiza cada 30 minutos se puede evitar las peticiones en peridos más cortos. | ||
| + | |||
| + | === Ignorar códigos === | ||
| + | HTTP tiene una serie de códigos internos para lidiar con distintos casos (200: todo ha ido corretamtente, 404: no se encontró el recurso, 500: hubo un error interno...) y que si se utilizan son una herramienta más que correcta para la comunicación cliente-servidor. \\ | ||
| + | Por ejemplo el 201 para cuando se ha creado un recurso, el 409 cuando ha habido un conflicto (por ejemplo de versiones de un recursos), el 412 para indicar que no se reconoce al cliente. | ||
| + | |||
| + | === Usar incorrectamente las cookies === | ||
| + | De la misma forma que las sesiones, el uso de cookies para mantener una conversación con el server; sí que podrían ser usadas para, por ejemplo, guardar un token de autentificación (aunque es preferible utilizar la autentificación HTTP). | ||
| + | |||
| + | === Olvidar la hypermedia === | ||
| + | El concepto de hypermedia corresponde al hecho de linkar elementos entre ellos. Olvidar la hypermedia es no agregar links en las representaciones de los recursos, es importante que los subrecursos sean devueltos como links. | ||
| + | |||
| + | === Ignorar los MIME types === | ||
| + | Puede que un recurso sea devuelto en distintos formatos (XML, JSON, YAML, PDF...), la forma adecuada de devolverlo al cliente es mediante el uso correcto de MIME-TYPES. | ||
| + | |||
| + | === Romper la auto descripción === | ||
| + | Básicamente es seguir los estándards REST. | ||
| ===== Notas ===== | ===== Notas ===== | ||
code/rest.1279360105.txt.gz · Última modificación: 2020/05/09 09:24 (editor externo)
Herramientas de la página
Excepto donde se indique lo contrario, el contenido de este wiki esta bajo la siguiente licencia: CC Attribution-Noncommercial-Share Alike 4.0 International
