2011-12-21 12 views
5

Objetivo: Una API REST
Pregunta: es el método que tengo debajo de un cierto API REST o es que falta algo así como me dijeron?
Esta es una cuestión de 3 partes ..¿Encabezados correctos para PHP RESTful Application?

Supongamos que tengo un proyecto PHP que tiene una API que devuelve datos en formatos XML o JSON, usted podrá acceder a la API como esto más adelante ...

server.com/article/123 | Returns ID 123 using GET 
server.com/article/new | Creates a new article using POST 
server.com/article/123/edit | Edits an article with the ID 123 using POST 
server.com/article/123/delete | Deletes article with ID 123 using POST 

1)
siempre he leído también que PUT debe ser usado para la edición de objetos, a continuación pongo la palabra POST como el usuario enviaría un POST a THT URI de la acción de eliminación, debo utilizar PUT en php usando algo como esto en su lugar?

$_PUT  = array();   
if($_SERVER['REQUEST_METHOD'] == 'PUT') {   
    parse_str(file_get_contents('php://input'), $_PUT);   
} 

2)
me dijeron en una pregunta que escribí en SO hace un tiempo que esto es similar a una API REST pero eso no es así, la respuesta que obtuve fue esta ...

In short, your service is not RESTful, but it is close. Rather than specify actions (edit, delete, ...) in URL segments, you will want to make use of HTTP verbs (GET, PUT, POST, DELETE).

o el chico no sabía lo que estaba hablando o simplemente no lo consigue, después de leer innumerables artículos sobre el tema, y ​​comparando con cada API que puedo encontrar, cómo es mi ejemplo anterior nO ¿Sosegado?

Me gustaría hacer una API RESTful, por favor me ayuda a corregir mi ejemplo anterior si es necesario?

3)
también asumiendo Planeo devolver una respuesta JSON para el usuario con algo como esto ...

<?php 
header('HTTP/1.1 200 OK'); 
header('Content-type: application/json'); 

$data = // my code that returns the appropriate data; 

echo json_encode($data); 
?> 

Es que la forma correcta de devolver el resultado a un usuario o soy yo ¿Echando de menos algo? Muchos artículos y preguntas hablan sobre el concepto pero no entran en el código real como mis ejemplos.

Respuesta

5

Para hacer frente a la parte 2 de su pregunta, una estructura de URL y el método más reparador sería la siguiente:

  • server.com/articles/123 - GET: devolver el artículo
  • server.com/articles/123-PUT: sustituir el artículo con el del cuerpo de solicitud
  • server.com/articles/123 - DELETE: eliminar el artículo
  • server.com/articles/-POST: crear un nuevo artículo

La idea aquí es que la URL representa el propio recurso (en este caso, el artículo) y el verbo, cuando sea práctico, indica lo que quiere hacer para eso. El mejor ejemplo que se me ocurre en la naturaleza de true RESTful API es la última versión de GitHub API: por lo que he visto, utilizan los métodos HTTP, los códigos de respuesta y los tipos MIME personalizados de forma adecuada.

En respuesta a la parte 3 de su pregunta, esa es sin duda una forma válida de hacerlo, pero si tuviera que usar un tipo MIME personalizado como application/vnd.myawesomesite.article+json, eso haría más fácil interpretar al final del cliente, como el cliente podría usar el tipo MIME para determinar cómo analizar el resultado: por ejemplo, el cliente podría enviar a diferentes deserializadores y clases según el tipo MIME presentado. Una vez más, la gente de GitHub da algunos ejemplos en their API docs.

+0

gracias voy a ver los tipos de mimo y la API API, también esa fue una de las mejores explicaciones. Lo único de lo que todavía no estoy seguro es del 'PUT' Si estuviera accediendo a esta API con PHP, ¿cómo podría enviar una solicitud' PUT' de lo que no estoy seguro. Lo siguiente en mi lista es Autenticación con algo como OAuth, si estoy enviando 'GET' a' server.com/articles/123', entonces no estoy seguro de cómo pasar en cualquier autenticación a menos que tal vez se envíe usando 'GET' también pero estoy seguro de que estos merecen su propia pregunta – JasonDavis

2
  1. Debería poder utilizar $_POST en una solicitud PUT, siempre que la solicitud incluya un encabezado Content-Type adecuado. Es un superglobal genérico que siempre debe llenarse cuando se envía un cuerpo HTTP y se usa el encabezado correcto de tipo de contenido. De hecho, incluso podría aparecer en una solicitud GET interrumpida.
  2. Sus URL pueden ser más RESTful. Por ejemplo, server.com/article/123 podría albergar no solo GET, sino también POST (editar) y DELETE (borrar). No es necesario usar URL separadas si ya está utilizando diferentes métodos de solicitud.
  3. RESTful describe principalmente la forma de comunicación entre el cliente y el servidor, no cómo lo hace. No he visto el encabezado 201 usado mucho en el pasado; por lo general, un 200 OK es lo suficientemente bueno. Por supuesto, nada debería impedir que uses el código 201.

#protip: ajusta todos sus datos en un objeto de resultado, como {'success':true,'result':<the result>,'resulttype':'article'}. Los desarrolladores que usan su API (si publica uno) lo encontrarán útil. Para ti esto significa que puedes agregar información extra a la respuesta fácilmente.

Very interesting article on FourSquare's REST API

+0

No estoy seguro de que me resulte útil. Debe usar el código de estado y los encabezados de respuesta para proporcionar metadatos (por ejemplo, si la solicitud fue exitosa), no el cuerpo de la respuesta. –

+0

@JohannesGorset Aunque estoy de acuerdo, los desarrolladores siempre preferirán tener esta información en el cuerpo de la respuesta también, ya que es más fácil para el desarrollo sin comprometer nada. Por supuesto, asegúrese de * también * enviar códigos de respuesta HTTP. –

+0

¡Al contrario! Yo argumentaría que dificulta el desarrollo al requerir que los clientes analicen datos arbitrarios del cuerpo de la respuesta para tamizar la información que ya tienen. –

Cuestiones relacionadas