rest - cities - api country state city list
Conseguir real con REST (7)
REST también es una interfaz "para el navegador" o solo para scripts
Ambos. De hecho, el navegador es en realidad un excelente ejemplo de un cliente REST. El hecho de que solo use un subconjunto de la interfaz HTTP no viola la restricción de la interfaz uniforme. POST es prácticamente un verbo comodín de todos modos. Los scripts se definen en la descripción de REST como "descarga de código" y forman parte integral de la interfaz REST.
Actualización: la restricción de la interfaz uniforme de REST no dice "debe usar todos los verbos disponibles" para ser REST. Dice que si usa un verbo, úselo para realizar una acción que sea consistente con el comportamiento esperado.
¿Deberíamos ver el mundo HTTP exclusivamente a través de los ojos de una representación REST?
No. REST generalmente se realiza a través de HTTP, pero HTTP no tiene dependencia de REST. Sin embargo, si está creando una aplicación web, debería considerar seriamente elegir el estilo arquitectónico REST para su solución. Puede que no sea la opción correcta, pero probablemente lo sea.
La solicitud GET /foo/?page=bar&action=delete rompe las reglas de HTTP y, por lo tanto, rompe la restricción REST de una interfaz uniforme. ¡Pero rompe HTTP primero!
Actualización: En la sección 9.1.1 de la especificación RFC 2616 de HTTP, se indica: "En particular, se ha establecido la convención de que los métodos GET y HEAD NO DEBEN tener la importancia de realizar una acción que no sea la recuperación". Realizar una acción de eliminación utilizando un GET es definitivamente romper las reglas de HTTP.
¿Deben el acceso web y la interfaz REST estar entremezclados o separados?
En mi opinión, deberían ser los mismos. De hecho, XHTML es en realidad un excelente formato para entregar resultados de IU y API. Está estandarizado, se puede analizar fácilmente, se puede ver en un navegador para propósitos de depuración, puede admitir hipermedia, se pueden usar microformatos para hacer marcado semántico, atributos de clase se pueden usar para definir cosas que los microformatos no cubren. ¿Qué más podrías querer?
Si está planeando hacer una interfaz de usuario HTML, ¿por qué hacer el mismo trabajo dos veces?
¿Puede Roy darnos una muestra simple?
Lea el artículo Cómo obtener una taza de café para obtener una buena idea de cómo debería funcionar una API REST.
Al leer el artículo recuerda este hecho importante que todos parecen haber olvidado:
Las interfaces REST deben ser FÁCILES DE USAR , NO SON FÁCILES DE DISEÑAR .
Busco un ejemplo decente de una API simple, completamente REST, sin éxito. Comprobado en stackoverflow también. Lo mejor que he visto es este post . A pesar de esto, todavía no entiendo el punto. Tomemos un ejemplo de una aplicación que todos conocemos: wikipedia.
Supongamos que queremos crear una API REST para wikipedia. Esperamos los siguientes verbos:
GET /wiki/Article_name: obtains a specified page
DELETE /wiki/Article_name: deletes the page
POST /wiki/Article_name: creates a new page
PUT /wiki/Article_name: updates a page.
El hecho es que cuando usa wikipedia con su navegador, no usa una interfaz REST para navegar por ella. Estoy bastante seguro de que cuando actualiza una página, nunca usa PUT (aunque técnicamente está creando una nueva revisión de una página, por lo que POST tiene sentido). Del mismo modo, cuando elimina una página, el navegador no envía un BORRAR.
Mis preguntas son:
- ¿Es REST también una interfaz "para el navegador" o solo para scripts?
- ¿Deberíamos ver el mundo HTTP exclusivamente a través de los ojos de una representación REST? ¿Hay cosas como GET / foo /? page = bar & action = delete todavía un punto de vista válido, o errores horribles del pasado que nunca se volverán a hacer?
- ¿Deben el acceso web y la interfaz REST estar entremezclados o separados? Por ejemplo, supongamos que tiene una aplicación de libreta de direcciones. Puede navegar por la libreta de direcciones con GET / people /, y con GET / people / 1523 obtiene la información de esa persona individual en el navegador, tal vez en un buen HTML imprimible. Si desea modificar su tarjeta, haría (RESTful) PUT / people / 1523, o en su lugar, tiene como PUT /api/v1.0/people/1523?
- ¿Podría alguien convencer a Roy Fielding para que se vuelva humano y proporcione un ejemplo de "niño de 5 años" para una REST API decente (en su opinión), en lugar de quejarse de lo que no es RESTful (en su opinión), para que todo el mundo pueda ¿seguir adelante?
Estás empapado en ello.
Sí, GET, PUT, POST y DELETE son todas las llamadas REST. La mayoría de las veces, estás usando GET o POST. Cuando va a una URL, se envía una solicitud GET al servidor web. Cuando envía un formulario, puede ser un GET o un POST, dependiendo del elemento. Sin embargo, DELETE y PUT son llamadas perfectamente válidas en las circunstancias adecuadas, como WebDAV. La página HTTP podría aclarar algo de eso.
REST, para el niño de 5 años, simplemente significa "El cliente envía una solicitud al servidor para cambiar el estado (agregar / reemplazar / eliminar / recuperar algo de contenido, en el caso de HTTP), y el servidor responde (posiblemente entregando contenido y el estado, posiblemente solo el estado), y la conversación finaliza. No hay conversación de ida y vuelta. Por lo tanto, casi CUALQUIER llamada normal a un servidor web es RESTful, ya sea desde su navegador, desde JavaScript o desde telnetting al puerto 80 desde Un programa terminal.
REST se usa generalmente en contraste con SOAP, donde un servicio web tiene la capacidad de describirse a sí mismo y su API a un cliente, y los servicios web pueden descubrirse a partir de directorios. Eso es mucho más complicado. Entonces, en su mayor parte, si no estás haciendo SOAP (y el jabón es tan complicado que no puedes hacerlo sin saberlo), estás haciendo REST.
Mientras me dirijo a los contrastes, algunos adictos a los buzzword contrastarán REST con AJAX. Son completamente ortogonales, y es perfectamente posible utilizar las técnicas AJAX para realizar solicitudes REST o solicitudes SOAP. AJAX, para el niño de 5 años, solo significa tener algún software ejecutándose en el navegador (podría ser JavaScript, pero también podría ser Java o Flash) hacer una solicitud HTTP al servidor y manejar la respuesta, en lugar del propio navegador , por lo que la pantalla no cambia hasta que el programa cliente que se ejecuta en el navegador decida modificar el DOM de la página que se muestra actualmente.
En cuanto a sus preguntas sobre si GET es una buena idea o no, "depende". GET pone la solicitud completa en la cadena de consulta. Eso significa que si esa es una solicitud que el usuario desea hacer de nuevo en algún momento (digamos que es una página de búsqueda o un enlace a una publicación de blog específica), se puede marcar como favorito. El inconveniente es que la cadena de consulta solo puede ser tan larga, y puede llevar a los usuarios a marcar partes de una URL que no deberían. POST, por otro lado, puede enviar contenido prácticamente ilimitado, pero no puedes marcarlo ni enviar una URL a un amigo (o enemigo, según el enlace). Tienes que usar el correcto para la situación. A veces necesitas el Philips, a veces necesitas el flathead.
Su ejemplo de GET / people / 1523 y PUT / people / 1523 es perfectamente válido, aunque es difícil de hacer con un servidor web normal, que no entenderá lo que quiere que haga PUT. "personas" tendría que ser un programa en algún lenguaje del lado del servidor que pudiera procesar la solicitud. Si estuviera usando los Servlets de Java, podría asignarse a un Servlet de cualquier nombre. Sería mucho más fácil separar su verbo de solicitud HTTP de su verbo de operación de datos, como GET / people / 1523 / get y POST / people / 1523 / update (o GET / people / get / 1523 y POST / people / update / 1523).
Recuerde: REST no es más que un conjunto de restricciones arquitectónicas para la computación distribuida, independientemente de cualquier protocolo de transporte subyacente. Cuando evalúa la capacidad de REST de una interacción cliente-servidor, realmente está comprobando si uno o más de estos elementos están rotos.
¿Es REST también una interfaz "para el navegador" o solo para scripts?
Cuando navegas en Wikipedia con Firefox, estás controlando un cliente REST. La falta de soporte para PUT y DELETE no resta valor a las restricciones de la interacción porque el significado de los verbos HTTP está fuera del alcance de REST. Un punto más cuestionable podría ser la forma en que los sitios y los navegadores admiten sesiones. Cuando cada solicitud debe entenderse en el contexto de una sesión, se podría decir que se rompe la restricción de la falta de estado de las solicitudes.
¿Deberíamos ver el mundo HTTP exclusivamente a través de los ojos de una representación REST? ¿Hay cosas como GET / foo /? page = bar & action = delete todavía un punto de vista válido, o errores horribles del pasado que nunca se volverán a hacer?
AFAIK, esto no rompe en sí mismo una restricción REST, a menos que la misma combinación URI / verbo haga dos cosas diferentes. En ese caso, estarías rompiendo la restricción de interfaz uniforme. Yo diría que este enfoque es malo desde la perspectiva de desviarse de la intención del protocolo HTTP, pero no desde la perspectiva de REST.
¿Deben el acceso web y la interfaz REST estar entremezclados o separados? Por ejemplo, supongamos que tiene una aplicación de libreta de direcciones. Puede navegar por la libreta de direcciones con GET / people /, y con GET / people / 1523 obtiene la información de esa persona individual en el navegador, tal vez en un buen HTML imprimible. Si desea modificar su tarjeta, haría (RESTful) PUT / people / 1523, o en su lugar, tiene como PUT /api/v1.0/people/1523?
No veo un problema con una API REST que funcione de manera diferente para los navegadores y para otros clientes REST. Lo más importante es proporcionar un comportamiento consistente en una clase de clientes. La versión de la API está fuera del alcance de REST.
¿Podría alguien convencer a Roy Fielding para que se vuelva humano y proporcione un ejemplo de "niño de 5 años" para una REST API decente (en su opinión), en lugar de quejarse de lo que no es RESTful (en su opinión), para que todo el mundo pueda ¿seguir adelante?
Así fue exactamente como me sentí después de leer ese post y enfrentarme a la casi total falta de ejemplos del mundo real.
La sugerencia de Darrel Miller para la taza de café es una buena idea. Si desea simplificar aún más, simplemente vuelva a su ejemplo inicial: el navegador. Todos los niños que he visto usando un navegador web entienden rápidamente cómo funciona. Comienzas en alguna página. Encuentras algo que te gusta. Sigues el enlace. Llegas a otra página. Encuentras algo que te gusta allí. Sigues ese enlace y llegas a otra página. Y así.
Es curioso lo difícil que se ha demostrado para reducir esta idea simple de practicar para clientes que no utilizan navegadores. Para inspirarse, puede consultar la API de Sun Cloud .
Respuesta parcial:
¿Hay cosas como GET / foo /? page = bar & action = delete todavía un punto de vista válido, o errores horribles del pasado que nunca se volverán a hacer?
Definitivamente lo último. Que yo sepa, ni siquiera hay ningún debate sobre este punto. Las solicitudes GET deben ser idempotent . Usar un GET para hacer una eliminación es un abuso terrible de la web, y me reiré implacablemente de quien lo haga cuando aparezca Googlebot y borre su base de datos.
Evitar que los motores de búsqueda te arruinen no es la única razón para no hacer esto, así que no te hagas una idea loca de hacerlo solo porque lo haces bajo autenticación.
Si desea tener un botón de eliminar, tenga un botón de eliminar. Si realmente desea que el botón se vea como un enlace, use javascript para hacer clic en el enlace ejecutar una publicación (o haga que el enlace GET una página de confirmación, que es totalmente aceptable).
Varios navegadores modernos aún no pueden enviar ninguna solicitud HTTP, excepto GET y POST . Bloquea una mayor aceptación de REST. Aunque hay algunas alternativas para los navegadores disponibles (vea esta presentación de David Heinemeier Hansson).
Según Tim Berners-Lee, las URL deben ser opacas (aunque hay un cierto debate aquí ), por lo que cosas como GET /foo/?bar=baz HTTP/1.1 están perfectamente bien en la medida en que GET mantiene idempotente y seguro.
Reutilizar las direcciones URL al acceder a ellas con diferentes tipos de medios se considera una buena práctica.
Creo que uno puede usar el protocolo de publicación RFC 5023 de Atom como ejemplo canónico de una API RESTful (al menos Roy Fielding comentó sobre algunos temas relacionados con ella).
EDIT1: Como veo en el mundo, para la mayoría de los programadores, REST como concepto va a ser una consideración al crear API. Por lo tanto, REST está en su lista de tareas pendientes cuando está creando una API para el consumo de las máquinas ; NO cuando estás hablando de páginas web con las que los seres humanos interactuarán a través de un navegador. EDIT2: Y eso no implica que el navegador no sea REST (lo es). Simplemente quiero decir que donde está la acción actual, donde la mayoría de los programadores del mundo (aquellos que no trabajan para un fabricante de navegadores) pueden beneficiarse de REST es principalmente en servicios web.
Tomemos un ejemplo de una aplicación que todos conocemos: wikipedia.
Está bien, pero no es el mejor ejemplo: Wikipedia es un sitio web rico, es decir, tiene un contenido rico creado para personas y no para computadoras.
GET / wiki / Article_name: obtiene una página específica
DELETE / wiki / Article_name: borra la página
POST / wiki / Article_name: crea una nueva página
PUT / wiki / Article_name: actualiza una página.
Su estructura de datos se basa en el modelo de uso humano de Wikipedia, de ahí la confusión.
A continuación, proporciono un ejemplo rápido de una API para Wikipedia, espero que sirva para ilustrar mi punto. Está hecho muy rápido; y no pretendo que sea un buen diseño de API. :-)
Nota 1: en el siguiente ejemplo de API, estoy usando JSON. En lo que respecta a "RESTfulness", no tiene que ser JSON, cualquier formato de datos que pueda intercambiarse de manera significativa a través de HTTP está bien. Así que otros ejemplos podrían ser XML, TXT, JPEG, AVI. En términos generales, "RESTfulness" se aplica a los encabezados de URL y HTTP, no al cuerpo de la página; el cuerpo queda libre para las necesidades específicas de las implementaciones.
Nota 2: estoy fingiendo que Wikipedia tiene un formato de datos estructurado interno que se transforma en páginas HTML, solo para ilustrar mi visión, ya que Wikipedia no es realmente el mejor ejemplo para trabajar con ...
Una primera oportunidad en una API RESTful para Wikipedia podría ser algo como:
api.wikipedia.com/search/keywords
Toma un GET con las palabras de búsqueda en la URL, devuelve un conjunto de datos JSON de ID de página , títulos de página, URL y puntajes de relevancia.
api.wikipedia.com/article/id/
Toma GET, DELETE, POST, PUT, y operará en el artículo con ID interna igual a "id" en la URL. Dependiendo del método HTTP de la solicitud, esto:
- OBTENER; devuelva el artículo (en el formato de datos basado en JSON predefinido de Wikipedia).
- BORRAR; eliminar artículo
- ENVIAR; crear nuevo artículo (el artículo debe estar en el cuerpo de la solicitud, en el formato JSON predefinido)
- PONER; Artículo de actualización (y toda la página debe ser enviada nuevamente en el cuerpo)
api.wikipedia.com/media/id/
Como el punto final del "artículo" anterior, pero para CRUD de medios como imágenes. .. y así sucesivamente, hasta que se cumplan todas las necesidades de esta API de Wikipedia imaginaria.
Un rápido vistazo a la API imaginaria anterior revela una serie de problemas ... y esa es la belleza de REST; es simple y no interfiere con la visualización del intercambio de datos.
¿Es REST también una interfaz "para el navegador" o solo para scripts?
EDIT3 El texto original era: No está diseñado para el navegador, es solo para las API destinadas al consumo por parte de otros clientes o servicios que son "máquinas".
Me gustaría cambiar esto a: El navegador es RESTful. También es un hecho, es decir, con la base instalada, y la cantidad extrema de tiempo que se tarda en reemplazar IE6, está claro que los navegadores que tenemos hoy nos acompañarán durante mucho tiempo. Y los navegadores actuales no hacen nada especial con los microformatos o los sitios con XHTML para la presentación de páginas y XHTML para la transferencia de datos, dejan todo eso para que lo haga usted mismo a través de Javascript.
Por lo tanto, con las tecnologías actuales, la mayoría del nuevo desarrollo que aplica REST está en la construcción de mejores API de servicios web. Y las consideraciones prácticas harán que las personas opten por colocar su API de servicio web en una URL diferente a la de su sitio web principal.
En relación con otras tecnologías de servicios web, REST tiene una ventaja significativa en la facilidad de depuración. Simplemente puede activar un cliente en su PC, enviar una URL y ver la respuesta de inmediato. (De acuerdo, lo mismo se aplica en cierta medida a muchos de los servicios web basados en XML; pero el XML generado por máquina no es práctico para que yo lo "lea").
¿Deberíamos ver el mundo HTTP exclusivamente a través de los ojos de una representación REST?
Ehh, no. El navegador maneja, ¿qué, el 97% del tráfico del sitio web de hoy en promedio?
¿Deben el acceso web y la interfaz REST estar entremezclados o separados?
Por separado, en el ejemplo anterior, utilicé api.wikipedia.com para ilustrar que está completamente separado del sitio regular de Wikipedia. Por consideraciones prácticas, como el equilibrio de carga, diferentes programas de lanzamiento, diferentes requisitos comerciales.