¿Es cierto que para implementar un API REST, uno tiene que poner en práctica una estructura de URL que tiene este aspecto¿Las URL de la API REST tienen que verse así?
http://example.com/post/
http://example.com/post/123
donde el /123 se utilizaría para editar, borrar
Otra forma de hacer la pregunta es: ¿puede una URL que se ve así llamarse RESTful?
http://example.com/script.php?method=get_title&blogid=123
Usted no tienen a diseñar la estructura de URI de esa manera. También podría ser /some_obscure_string/base64_encoded_title/unique_id. Esto también podría ser RESTful, dependiendo de varios otros factores.
Pero existen varias mejores prácticas sobre cómo diseñar URI en una aplicación web RESTful y es tan simple y tan legible como sea posible.
Su ejemplo http://example.com/script.php?method=get_title&blogid=123 también podría ser RESTful, pero los parámetros de consulta indican que en su lugar se usa algún tipo de RPC o RMI sobre HTTP.
Para resumir: no piense demasiado en el diseño de su URI. Esto vendrá automáticamente con un diseño RESTful bueno y apropiado de su aplicación.
Ejemplo URL:
GET http://del.icio.us/api/
GET http://del.icio.us/api/peej/tags/
GET http://del.icio.us/api/peej/tags/test
DELETE http://del.icio.us/api/peej/bookmarks/[hash]
La idea detrás resto es que cada recurso tiene su propia URL y utilizar los diferentes métodos HTTP para interactuar con esos recursos. Tiene sentido definir la estructura de la URL para que la jerarquía entre los diferentes recursos se refleje en la URL, pero no es necesario.
Si tiene direcciones URL como esta
/all-posts/
/first-post
/some-stuff/second-post
/third-post
todavía podría proporcionar una API REST a esto. La Idea es que GET a /all-posts/ devuelve una lista de las URL de cada objeto de publicación y el cliente usa esas URL para interactuar con los recursos. Básicamente, el cliente debe tratar las URL como datos opacos.
Mientras la URL que está incrustada en el cliente no cambie, también podría cambiar la estructura sin tener que cambiar el cliente.
Su URL de ejemplo probablemente no pertenezca a una API RESTful, ya que contiene un método get_title. En REST una URL representa una cosa . Lo que se debe hacer con la cosa (si se debe modificar, si se debe recuperar el contenido, ...) no es parte de la URL, porque REST usa los diferentes métodos HTTP.
El concepto REST se basa realmente en el hecho de que es impulsado por URL, y no está impulsado por grandes blobs de datos. Con REST, no tiene que pasar una solicitud de jabón gigante para invocar un método: su invocación de método/creación de objeto/lo que quiera hacer se invoca simplemente por la URL y el verbo que utilizó frente a esa URL.
Un aspecto clave de REST es que la url es el recurso. un uri como
http://example.com/script.php?etc-etc-etc
no coloca el identificador de recursos en la parte de recursos del uri.eso no quiere decir que una API RESTful no deba usar parámetros get; De hecho, eso está bien:
http://example.com/posts?sort=date_asc&offset=20&limit=10
podría ser una gran manera de conseguir el URI de la tercera página de los mensajes más antiguos. Sin embargo, el uso de los parámetros get de esta manera solo debe usarse en solicitudes donde el método también sea GET. PUT y especialmente POST métodos realmente deberían usar uri simples con el recurso que se verá afectado solo en la parte de ruta.
La estructura de sus URL no es importante. Lo que importa es que cada URL identifica exactamente 1 recurso. Cada recurso puede tener múltiples URL que apuntan a él, pero cada URL solo debe apuntar a 1 recurso.
El diseño RESTful URI tiene que ver con el acceso a los recursos y debe estructurarse de manera RESTful, por lo que no debe tener cadenas de consulta.
p. Ej. de GET
autores/
autores/1
autores/1/libros
autores/1/libros/10
autores/1/libros/10/resumen
etc.
Cualquier cosa y todo se llama RESTfull en estos días , solo mira algunas de las respuestas de su inventor, el Dr. Roy Fielding, y obtendrás algunas ideas. Vale la pena leer sobre el tema.
P.S no necesita publicar, obtener etc. en sus URI, actualmente el protocolo HTTP se utiliza principalmente para consumir API REST y puede pasar el verbo como parte de la llamada. También existe un concepto de negociación de contenido, es decir, puede solicitar cualquier formato disponible desde la API REST (json, xml atc).
+1 para el último punto – rojoca
+1 para "lo más simple y lo más humano posible" – AlcubierreDrive