1. Inicio
  2. Pregunta y respuesta
  3. ¿Puede explicar el concepto web de RESTful?

¿Puede explicar el concepto web de RESTful?

2009-02-16 11 views

Respuesta

35

Una aplicación REST es una aplicación que expone su estado y funcionalidad como un conjunto de recursos que los clientes pueden manipular y se ajusta a un cierto conjunto de principios:

  • todos los recursos son únicamente direccionable, generalmente a través de URIs ; otro direccionamiento también puede ser utilizado, sin embargo.
  • Todos los recursos se pueden manipular a través de un conjunto restringido de acciones conocidas, generalmente CRUD (crear, leer, actualizar, borrar), representadas más a menudo a través de HTTP POST, GET, PUT y DELETE; aunque puede ser un conjunto diferente o un subconjunto; por ejemplo, algunas implementaciones limitan ese conjunto para leer y modificar solamente (GET y PUT) por ejemplo
  • Los datos para todos los recursos se transfieren a través de cualquiera de un número limitado de pozos. representaciones conocidas, generalmente HTML, XML o JSON;
  • La comunicación entre el cliente y la aplicación se realiza a través de un protocolo sin estado que permite intermediarios en múltiples capas que pueden redirigir y almacenar en caché las solicitudes y los paquetes de respuesta de forma transparente para el cliente y la aplicación.

El Wikipedia article señalado por Tim Scott proporciona más detalles sobre el origen de REST, principios detallados, ejemplos, etc.

Fuente

2009-02-16 01:09:01

+7

Lamentablemente, deducir que los mapas CRUD para OBTENER, PONER, PUBLICAR, ELIMINAR es extremadamente engañoso cuando intenta comprender DESCANSO. La siguiente pregunta es siempre, "pero, ¿y si tengo que hacer otras operaciones?". Como mencionas en un comentario posterior, PUT puede crear y, como explico, POST no puede crear. Olvídate de CRUD! –

+0

XML y Json son tipos de medios horribles para usar en REST. El único escenario en el que realmente funcionan es cuando se realiza AJAX en un navegador en el que se está descargando un script de Java que comprende el formato de XML/JSON. En otros escenarios, necesita usar un tipo de datos más semánticamente significativo. –

+0

@Darell: XML y JSON son dos de los formatos de representación de recursos más utilizados, por lo que deben mencionarse, independientemente de si son los mejores. Lo mismo aplica para CRUP y su mapeo de verbos HTTP. –

2

Significa el uso de nombres para identificar tanto comandos como parámetros.

En lugar de nombres que sean meros identificadores o apodos, el nombre en sí mismo contiene información. Específicamente, información sobre lo que se solicita, parámetros para la solicitud, etc.

Los nombres no son "raíces" sino más bien acciones más datos de entrada.

Fuente

2009-02-16 00:47:39

+0

Mejor explicación alguna vez – AymenDaoudi

6

Francamente, la respuesta depende del contexto. REST y RESTful tienen significados que dependen del idioma o marco que estés usando o de lo que trates de lograr. Como ha etiquetado su pregunta en "servicios web" responderé en el contexto de los servicios web RESTful, que todavía es una categoría amplia.

Los servicios web RESTful pueden significar cualquier cosa desde una interpretación REST estricta, donde todas las acciones se realizan de una manera estrictamente "RESTful", a un protocolo que es XML simple, lo que significa que no es SOAP o XMLRPC. En el último caso, este es un nombre inapropiado: un protocolo REST como este es realmente "plain old XML" (or "POX") protocol. Mientras que los protocolos REST usualmente usan XML y, como tales, son protocolos POX, esto no necesariamente tiene que ser el caso, y el inverso no es verdadero (simplemente porque un protocolo usa XML no lo hace RESTful).

Sin más, una verdadera API REST consiste en acciones tomadas en objetos, representadas por el método HTTP utilizado y la URL de ese objeto. Las acciones son sobre los datos y no sobre lo que hace el método. Por ejemplo, las acciones de CRUD (crear, leer, actualizar y eliminar) pueden asignarse a un determinado conjunto de URL y acciones. Digamos que estás interactuando con una API de fotos.

  • Para crear una foto, debe enviar datos a través de una solicitud POST a/fotos. Le permitirá saber dónde está la foto a través del encabezado de ubicación, p./photos/12345
  • Para ver una foto, debe usar GET/photos/12345
  • Para actualizar una foto, debe enviar datos a través de una solicitud PUT a/photos/12345.
  • Para eliminar una foto, debe usar DELETE/photos/12345
  • Para obtener una lista de fotos, debe usar GET/fotos.

Se pueden implementar otras acciones, como la capacidad de copiar fotos mediante una solicitud COPY.

De esta forma, el método HTTP que está utilizando se correlaciona directamente con la intención de su llamada, en lugar de enviar la acción que desea realizar como parte de la API. Para contrastar, una API no RESTful podría usar muchas más URL y solo usar las acciones GET y POST. Por lo tanto, en este ejemplo, es posible que vea:

  • Para crear una foto, envía un POST a/fotos/Crear
  • Para ver una foto, envía un GET a/fotos/view/12345
  • Para actualizar una foto, envíe un mensaje POST a/fotos/actualizar/12345
  • Para eliminar una foto, envíe un GET a/photos/delete/12345
  • Para obtener una lista de fotos, envíe un GET a/photos/list

Usted observe cómo en este caso las URL son diferentes y los métodos se eligen solo por necesidad técnica: para enviar datos, debe usar un POST, mientras que todas las demás solicitudes usan GET.

Fuente

2009-02-16 01:13:13 wuputah

+0

en realidad, POST se utiliza para representar Crear y PONER para actualizar. sin embargo, dado que algunas implementaciones de servidor no admiten PUT de forma nativa, POST está sobrecargado para ambas operaciones. –

+0

Eso es una cuestión de debate, de verdad. PUT se usa a menudo para la creación. :) – wuputah

+0

Disculpe, no hay debate. :-) RFC 2616 especifica exactamente las operaciones para POST y PUT. El párrafo 2.5, método POST solicita que la entidad incluida sea aceptada como un nuevo subordinado de la URL solicitada. Parrafo 26, el método PUT solicita que la entidad incluida se almacene en la URL especificada. –

4

sólo algunos puntos:

  • reparador no depende de la estructura que utilice. Depende del estilo arquitectónico que describe. Si no sigue las restricciones, no es RESTful. Las limitaciones están definidas en media página del Capítulo 5 del documento de Roy Fielding, lo invito a que vaya y lo lea.
  • El identificador es opaco y no contiene información más allá de la identificación de un recurso. Es un nmae, no datos de entrada, solo nombres. en lo que respecta al cliente, no tiene lógica o valor más allá de saber cómo construir querystrings desde una etiqueta de formulario. Si su cliente construye sus propios URI usando un esquema que ha decidido de antemano, no estará tranquilo.
  • El uso o no de todos los verbos http no es realmente la restricción, y es perfectamente aceptable diseñar una arquitectura que solo admita POST.
  • El almacenamiento en caché, el alto desacoplamiento, la falta de estado de sesión y la arquitectura en capas son los puntos de los que pocos hablan, pero los más importantes para el éxito de una arquitectura RESTful.

Si no pasa la mayor parte de su tiempo elaborando su formato de documento, probablemente no esté haciendo REST.

Fuente

2009-02-16 06:41:22 SerialSeb

12

La mejor explicación que encontré está en este .

Fuente

2009-02-17 20:11:51

10

RESTO a modo de ejemplo:

POST /user 
fname=John&lname=Doe&age=25

El servidor responde:

200 OK 
Location: /user/123

En el futuro, a continuación, puede recuperar la información de usuario:

GET /user/123

El servidor responde:

200 OK 
<fname>John</fname><lname>Doe</lname><age>25</age>

Para actualizar:

PUT /user/123 
fname=Johnny

Fuente

2009-07-04 07:22:01 pbreitenbach

Cuestiones relacionadas

 Cuestiones relacionadas