2010-03-06 20 views
5

He leído muchos tutoriales de descanso para PHP.es tranquilo solo para servicios web O para servicios web Y páginas web?

(no me quiero ir a fondo sobre por qué no estoy usando RoR. Es debido a que el equipo estar más familiarizados con PHP)

Debido a que estamos planeando para una futura expansión en las API que tienen que leí que es importante implementar servicios web tranquilos.

He mirado tutoriales como

http://www.gen-x-design.com/archives/create-a-rest-api-with-php/

Al parecer reparador que se entiende por servicios web.

¿Qué tal para las páginas web? ¿Pueden ser DESCANSABLES también?

si la respuesta es NO, por favor no va más allá de esta línea Y solo dígame. Gracias.

Sé que hacer que las urls se vean como URLs REPOSO es simplemente usar mod_rewrite. Sin embargo, estoy bastante seguro, la arquitectura tranquila va más allá de hacer que las urls se vean bien.

Por ejemplo, tengo una lista de elementos en una página web llamada list.php. Cada elemento tiene un enlace de eliminación al lado. Por ejemplo, list.php? Id = 1 & DeleteItem

Lo que pasa es que cuando alguien hace clic en el list.php? Id = 1 & enlace DeleteItem, por supuesto vuelvo al mismo archivo list.php y compruebe si hay el param deleteitem en $ _GET.

Si lo detecta, lo eliminaré de la base de datos basado en el identificador de parámetro en $ _GET.

Después de lo cual volveré a dirigirme a list.php SIN parámetros.

Me pregunto, ¿cómo puedo hacer que todo este flujo sea EXTENSO?

Lo estoy preguntando porque en REST, para hacer que se elimine algo, debe usar el método de solicitud HTTP (DELETE).

Es evidente que en mis enlaces todos ellos son simplemente <a href="list.php?id=1&deleteitem">Delete</a>

favor me ilumine.

Mi programación no es tan fuerte y sería bueno si el consejo dado puede ser tan sencillo como sea posible.

Gracias.

EDITAR

tengo 2 preguntas de seguimiento.

pregunta 1) Dado que esta es una lista de elementos con paginación, ¿cómo se vería la URL si quiero que sea RESTful?

pregunta 2) Desde que estoy poniendo eliminar vínculos al lado de cada uno de los elementos de la lista, ahora entiendo, yo debería usar

<form method="POST"> 
<input type=hidden name="_method" value="delete"> 
<input type="submit" > 
</form> 

lugar.

sin embargo, ¿el formulario debe publicarse en dónde? la URL del artículo?/items/{item-id}

Pero quiero volver a esta página de listado que muestra un mensaje de éxito DESPUÉS de eliminar con éxito la fila en la base de datos.

También quiero evitar un mensaje emergente cuando actualizo esta página de la lista con el mensaje de éxito.

Si vuelvo a publicar en esta URL list.php, entonces no es RESTful sí? porque las siguientes respuestas me dicen que cada elemento es un recurso que necesita su propia URL.

Por favor aclararme. Gracias.

Respuesta

6

RESTful se usa comúnmente cuando se hace referencia a servicios web, pero se puede aplicar a páginas web. En pocas palabras, ser RESTful se trata de manejar los recursos. Un recurso puede ser una persona, un libro, una película, un teatro, un boleto o lo que sea que desee.

Hay cuatro operaciones básicas que puede realizar en un recurso.

  • crear (POST)
  • lectura (GET)
  • actualización (PUT)
  • BORRAR (DELETE)

mayoría de los navegadores no son compatibles con las acciones PUT y DELETE, por lo solo puedes usar acciones POST para enviar datos. Rails falsifica PUT y DELETE al pasar un parámetro oculto llamado _method que el marco recoge y lo enruta según ese valor.

Además, nunca debe usar GET para ninguna acción destructiva. Cualquier acción que cambie el estado de sus recursos, debe llamarse con POST, PUT, o DELETE dependiendo del cambio (falso PUT/DELETE con POST si es necesario).

Le sugiero que compruebe la manera en que el enrutamiento REST se maneja en Rails solo para hacerse una idea, si nada más. Aunque las cuatro acciones anteriores son suficientes para modificar un recurso de cualquier manera posible, Rails también introduce otros tres tipos de acciones que parecen útiles.

  • índice
  • nueva (vista de todos los elementos de la lista) (por lo general una vista de formulario para agregar un nuevo recurso )
  • de edición (por lo general una vista de formulario a actualización de un recurso existente)

Pretty URL está definitivamente sobre la mesa cuando se diseñan sitios RESTful, pero probablemente la mayor ganancia es que la calidad del código mejora automáticamente. Cuando solo se trata de recursos, y solo hay cuatro acciones potenciales que se pueden aplicar a un recurso, entonces las cosas comienzan a limpiarse por sí mismas.

Editar 1: auto-descriptivo de URL son los preferidos y le hará la vida más fácil, pero no hay nada que impida la creación de direcciones URL crípticos que identifican de forma única un recurso y lo gestionan utilizando los verbos HTTP. Las URL como las siguientes (usando md5) para identificar de manera única los recursos son perfectamente RESTful.

// represents a person "John Doe" 
http://example.com/4c2a904bafba06591225113ad17b5cec 

// represents the movie "Lord of the Rings: The Two Towers" 
http://example.com/1d9198260dec7bda3fb21e232d60fec3 

// represents the "Formula One" sport 
http://example.com/fs340as?id=23xa12&type=SP012Ts 

Eso es REpresentational State Transfer right there. El hash MD5 es como la dirección postal del recurso que permanece constante. La representación podría ser los detalles de la película (en html/xml/json/etc.), O tal vez el video de la película en sí, dependiendo de las capacidades del cliente).

Editar 2: Digamos que usted tiene un recurso que es una colección - countries del mundo. Podría ser representado por un verbo URI y HTTP, tales como:

GET /countries 

Desde paginación es una propiedad de la aplicación en lugar del propio recurso, se puede proporcionar parámetros de cadena de consulta para su control.

GET /countries?page=1 

Un país es también un recurso que forma parte del recurso de los países. Se podría identificar a un país con un enlace como:

/countries/<id> 

y operaciones en este país se podrían realizar con estos verbos:

GET /countries/<id> 
POST /countries -- the new country has no existing representation 
PUT /countries/<id> 
DELETE /countries/<id> 
+0

Tengo una pregunta. Para los formularios que usan POST, no quiero que mi usuario vea la ventana emergente cuando usan los botones para volver atrás y refrescar en su navegador. Entonces, ¿cómo superar esto mientras sigo siendo RESTful? –

+1

revise esta pregunta para obtener ideas sobre cómo solucionarlo: http://stackoverflow.com/questions/660329/prevent-back-button-from-showing-post-confirmation-alert – Anurag

+0

Tengo una pregunta sobre la vista de lista de todos artículos. No estoy tan familiarizado con Rails, así que tengo que preguntarte en su lugar. Para la paginación de listas, ¿cómo lo manejaría un marco RESTful? –

1

El enfoque relajante también se puede utilizar con seguridad en las páginas web. Poner comandos en una URL no es una buena idea, debido a los efectos secundarios que mencionas. Cuando cambie la base de datos (o haga lo que cambie el modelo), use los comandos POST.

Por supuesto, usted no tiene PUT y BORRAR en los principales navegadores web, pero siempre se puede enviar un simple post con algún parámetro específico como method = "PUT", method = "Borrar", etc.

+0

Llamaría al parámetro method = PUT o method = DELETE: D – aefxx

+0

aefxx: buena idea, por supuesto, "method" tiene más sentido que "job" – naivists

+0

Tengo una pregunta. Para los formularios que usan POST, no quiero que mi usuario vea la ventana emergente cuando usan los botones para volver atrás y refrescar en su navegador. Entonces, ¿cómo superar esto mientras sigo siendo RESTful? –

2

Respuesta larga corta: sí. REST es para ambos. Esto se debe a que, incluso si tiene uno de los sitios web más simples, aún tendría que OBTENER su página y POSTAR los datos personales para agregar una entrada al libro de visitas. En eso, todos nos adherimos a REST de alguna manera.

En su caso, la implementación deficiente del navegador dificulta la implementación de un modo RESTO PURO. DELETE no es compatible sin Javascript y, por lo tanto, tendría que usar GET o POST (que tienen un significado totalmente diferente de DELETE en REST) ​​de todos modos.

1

me escribió un marco pequeño en la parte superior de Zend Framework para realizar la implementación las interfaces REST más fácil: las

http://github.com/mikekelly/Resauce

puede utilizar este último para los servicios web y sitios web. Esencialmente, un sitio web es solo un servicio web impulsado por HTML.

+0

Debido a ciertas razones, no estamos utilizando Zend Framework. ¿Todavía puedo usar Resauce para ayudarme en mi situación como se describe arriba? Gracias. –

+0

Resauce está creado a partir de los componentes MVC de ZF, por lo que no. Hay otros proyectos como el pegamento (http://gluephp.com/about), Limonade, etc. – Mike

1

RESTful significa que no hay "URI hermosas". A pesar de que los URI identifican un recurso, lo único que dice REST sobre los URI es que no deben contener un parámetro de acción como "eliminar".

En el caso de que le llame

DELETE /items/6793 

la respuesta sería típicamente código de estado 200 OK con la lista modificada como cuerpo del mensaje.Ver: http://restpatterns.org/HTTP_Methods/DELETE

Dado que HTML 4 no es compatible con otras acciones de formulario que GET y POST, debe solucionar el problema con un parámetro oculto y anular el método HTTP en el lado del servidor.

+0

incluso si utilizo el formulario POST para eliminar el artículo, ¿cómo puedo volver a dirigirme a la página del listado?He editado mi pregunta para incluir esta consulta –