http - name - ¿Un sitio web también debería ser un recurso web?

meta name keywords (4)

Estoy en desacuerdo con la otra respuesta de que esta decisión debería tener algo que ver con SEO o cuán "amigable" es una URL (¡los robots también son [escritos por] personas!). Pero mi intuición me dice que obtendría mejores resultados de SEO al unir los URI, ya que eso también unifica el pagerank en el evento (poco probable) al que los URI de API se vincularían desde la web salvaje del mundo.

En qué debe descansar esta decisión es de lo que son capaces sus servidores y clientes. Si pueden establecer los encabezados de solicitud Aceptar, y su servidor es lo suficientemente inteligente como para hacer una negociación de contenido transparente, entonces, por supuesto, unificar los URI. Esto es lo que hago (mi único cliente JSON es yo mismo, emitiendo solicitudes AJAX servidas desde otras partes HTML de mi aplicación web, donde controlo el encabezado Accept).

Si un cliente no puede establecer encabezados de solicitud, como un usuario web que desea obtener la respuesta json, terminará con el valor predeterminado (presumiblemente text / html). Por esta razón, es posible que desee permitir que las respuestas no negociadas se produzcan en URI únicos (/foo.txt, /foo.rtf). Convencionalmente, esto se hace agregando el formato al URI separado por un punto, como si fuera una extensión de nombre de archivo (pero normalmente no lo es, mod_rewrite hace los malabares) para que los clientes antiguos en plataformas que necesitan extensiones de nombre de archivo puedan guardar el archivo con uno significativo.

La mayoría de las páginas de mi sitio funcionan de la siguiente manera:

Determine la consulta SQL desde la URL de solicitud. (ej. /cars?colour=black => SELECT * FROM cars WHERE colour=''black'' )
Emitir consulta SQL.
Determine el tipo de respuesta aceptable de la lista admitida por este archivo. Esto suele ser HTML y HAL (es decir, JSON), aunque a veces XML también. Vuelva a text/html si nada más es aceptable.
if (HTML) escupió <HEAD> y <NAV> (teniendo en cuenta los parámetros: <h1>Black Cars</h1> )
escupir resultados usando el tipo de respuesta más aceptable.
Esta función sabe cómo tomar un objeto de resultado SQL y convertirlo en encabezados de HTTP Link , una secuencia de elementos HTML <LINK> , la clave _links de HAL, una secuencia de elementos XLink, un elemento HTML <TABLE> (con celdas que contienen <A> elementos), o un archivo CSV. La consulta SQL puede devolver 0 filas, en cuyo caso se escribe un mensaje fácil de usar en lugar de una tabla HTML si esa salida se estaba utilizando.
si (HTML) escupió <FOOTER>

Este esquema básico maneja alrededor de 30 colecciones de recursos diferentes en mi aplicación web, aunque cada una tiene un conjunto diferente de opciones que el URI de solicitud puede invocar, por lo que el inicio de cada una difiere en términos de validación de parámetros.

Entonces, ahora que he explicado todo eso, pueden ver cómo podría ser útil tener todos los detalles de cada recurso manejado en un solo lugar, y los genéricos de salida en formato X o formato Y manejados por una función de biblioteca común. Es un detalle de implementación que me facilita la vida y me ayuda a adherirme a la máxima de No repetirme.

Cada aplicación web, cada sitio web, es un servicio. (...) Las características que hacen que un sitio web sea fácil de usar para un internauta también hacen que un API de servicio web sea fácil de usar para un programador.
Richardson y Ruby, "Servicios web RESTFul"

Tal como lo pretendo, un sitio web que también es un servicio web proporciona múltiples representaciones de sus recursos, según lo que solicite el usuario-agente. La API, por así decirlo, es el sitio web en sí, y no se proporciona por separado.

Este no es el caso de muchas "API REST" populares en la naturaleza. La API de Twitter, por ejemplo, se encuentra en http://api.twitter.com/1/ , el ''1'' en el URI es la versión de la API en sí. Socialcast también proporciona una API REST en https://demo.socialcast.com/api/ , el nombre de tercer nivel es el nombre de la red a la que se dirige.

Esto me parece mal. Si tengo mi blog en http://www.example.com/blog , no debería necesitar proporcionar una API en una ubicación diferente, sirviendo JSON solo para robots. En lugar de tener http://www.example.com/blog/posts/ y http://api.example.com/blog/posts , dos URI diferentes, debería tener solo la primera y varias representaciones disponibles, entre las cuales application/json para la API JSON que deseo proporcionar a mis usuarios.

Ejemplo 1 : un navegador que solicita las publicaciones en mi blog;

Solicitud:

curl -i / -H "Accept: text/html" / -X GET / http://www.example.org/blog/posts/

Respuesta:

200 OK Content-Type: text/html; charset=utf-8 <html><body><h1>Posts</h1><ol><li><h2>My first post ...

Ejemplo 2 : el mismo URI, pero esta vez un robot hace la solicitud;

Solicitud:

curl -i / -H "Accept: application/json" / -X GET / http://www.example.org/blog/posts/

Respuesta:

200 OK Content-Type: text/html; charset=utf-8 { "posts": [ { "id": 1, "title": "My first post" ...

Los números de versión para las API deben codificarse en el campo "Aceptar" de los encabezados de solicitud y, sobre todo, evitar escribir fuertemente los URI como Twitter ("status / show.json? Id = 210462857140252672" o "status / show / 210462857140252672.json" ").

Podría perder algo de flexibilidad apostando por el enfoque unificado (pero, ¿no deberían los URI Cool nunca cambiar? ), Pero creo que adherirme a REST (o al menos mi interpretación) proporcionaría más beneficios.

¿Cuál es el enfoque más correcto: separar la API y el sitio web o unificarlos?

La Web y una API RESTful pueden comportarse de diferentes maneras.

En teoría, ¿cómo una solicitud como http://mysite.com/blog/1 distingue si necesita devolver una página HTML o solo los datos (JSON, XML ...)? Votaré por usar el encabezado Accept http :

Accept: text/html <-- Web browsers Accept: application/json <-- Applications/Relying parties consuming data or performing actions

¿Por qué Twitter, Facebook u otros sitios no mezclan navegadores web y partes confiantes? Honestamente, yo diría que es una decisión arbitraria.

Tal vez pueda proporcionar una posible razón: las URL de los exploradores web / robots de los motores de búsqueda deberían ser URL amigables porque funcionan mejor en SEO. Por esa razón, tal vez las URL listas para SEO no son muy semánticas en términos de REST, ¡pero son para motores de búsqueda o incluso para usuarios humanos!

Finalmente: ¿qué es mejor (es mi opinión)?

Necesita SEO , luego use URL separadas .
No necesita SEO , luego unifique las URL en el mismo dominio y formato .

Definitivamente no estoy de acuerdo con el enfoque del sitio web == del servicio web.

En pocas palabras, el sitio web debe tratarse como un cliente, solo un cliente, que consume el servicio web y presenta los datos en una forma adecuada para su uso en la web. Al igual que una aplicación móvil, es un cliente, solo un cliente, que consume el mismo servicio web y procesa los datos en una forma adecuada para el uso móvil.

El servicio web es el proveedor de servicios. Todos los demás son solo clientes; sitio web, aplicación de Android, aplicación para iphone, ... etc.

No hay correcto o incorrecto aquí. Seguir REST y RFC demasiado de cerca puede resultar difícil cuando su desarrollo de API se basa en requisitos específicos del cliente.

En realidad, los usuarios humanos tienen diferentes patrones de comportamiento en comparación con los clientes API, y por lo tanto requieren un tratamiento diferente. La distinción más vívida proviene del hecho de que muchas API son muy intensivas en datos, diseñadas para operaciones por lotes y descarga de datos, mientras que las aplicaciones para usuarios humanos son más "reactivas" y a menudo lo hacen paso a paso, solicitud por solicitud. Como consecuencia, en muchos proyectos, el diseño de las direcciones URL de las API está optimizado para evitar desperdiciar los recursos del cliente y del servidor en múltiples recorridos de ida y vuelta de redes y repeticiones de llamadas de almacenamiento.

Bajo el capó, las implementaciones de API a menudo tienen un diseño diferente de la aplicación principal, optimizado para el tipo de operaciones que proporcionan las API. Por ejemplo, la implementación de API puede usar una estrategia de almacenamiento en caché por separado. Ahora, si divide el código, es posible que desee crear un clúster de hosts que solo maneje las llamadas API. Ahí es donde colocar la API en otro dominio resulta beneficioso para la gestión de la carga : un dominio separado permite un equilibrio de carga más simple en sitios de alta carga. En comparación, cuando usa / api URL prefix en el mismo nombre de dominio (pero tiene clusters separados), entonces necesita un equilibrador de carga inteligente (L7-aware) para hacer el trabajo de dividir el flujo de solicitudes entre API y clústeres de front-end web, pero tales equilibradores de carga son más caros.

Por lo tanto, puede haber muy buenas razones técnicas por las cuales los gustos de Twitter separan la API, pero las referencias a otras implementaciones pueden no aplicarse a SU proyecto. Si se encuentra en las primeras etapas de diseño, puede comenzar con un esquema de URL unificado en el mismo dominio, pero eventualmente puede encontrar que hay buenos casos de uso de la vida real que le hacen cambiar el enfoque, y luego ... refactorización

PD: hay una larga discusión sobre el control de versiones aquí. ¿ Mejores prácticas para el control de versiones de API?

PSS Creo que las URL fuertemente tipadas son útiles para la depuración rápida. Simplemente puede poner una URL en el navegador con .json y obtener rápidamente el resultado sin cambiar a la línea de comando. Pero estoy de acuerdo con usted en que el encabezado "aceptar" es el método preferido

PSSS SEO para API? Puedo ver cómo un buen diseño de URL puede ser beneficioso, pero para un motor de búsqueda es probablemente irrelevante si su servicio proporciona múltiples formatos de salida en la misma ruta / nombre de dominio. Al final del día, los motores de búsqueda están diseñados para usuarios humanos, y los usuarios humanos no consumen XML y JSON.