¿Cuándo utiliza encabezados HTTP personalizados en la parte de solicitud de una API REST?API REST: encabezados HTTP personalizados frente a parámetros de URL
Ejemplo:
¿Alguna vez utiliza
GET /orders/view
(custom HTTP header) CLIENT_ID: 23
en lugar de
GET /orders/view/client_id/23 or
GET /orders/view/?client_id=23
La URL indica el recurso en sí. Un "cliente" es un recurso sobre el que se puede actuar, por lo que debe formar parte de la url base: /orders/view/client/23.
Los parámetros son solo eso, para parametrizar el acceso al recurso. Esto especialmente entra en juego con publicaciones y búsquedas: /orders/find?q=blahblah&sort=foo. Hay una línea muy fina entre los parámetros y los sub recursos: /orders/view/client/23/active versus /orders/view/client/23?show=active. Recomiendo el estilo de los recursos secundarios y los parámetros de reserva para las búsquedas.
Dado que cada punto final REpresenta una Transferencia de estado (para modificar la regla mnemotécnica), los encabezados personalizados solo deben usarse para elementos que no incluyen el nombre del recurso (la url), el estado del recurso (el cuerpo) , o parámetros que afectan directamente al recurso (parámetros). Eso deja verdaderos metadatos sobre la solicitud de encabezados personalizados.
HTTP tiene una selección muy amplia de encabezados que cubren casi todo lo que necesita. Donde he visto encabezados personalizados aparece en una solicitud de sistema a sistema que funciona en nombre de un usuario. El sistema proxy validará al usuario y agregará "X-User: userid" a los encabezados y usará las credenciales del sistema para llegar al punto final. El sistema de recepción valida que las credenciales del sistema están autorizadas para actuar en nombre del usuario, y luego valida que el usuario esté autorizado para realizar la acción.
No hay un estándar para RESTO sin embargo, la forma aceptada sería
GET /orders/view/23
usin g los encabezados personalizados y, por lo tanto, el 23 después de la vista asume que es el ID, por lo tanto, tendría una función que toma el ID y, por lo tanto, produce solo esa información.
No utilizaría encabezados personalizados ya que no sabe si algún proxies los pasará. Basado en URL es el camino a seguir.
GET/órdenes/view/cliente/23
No recomendaría encabezados personalizados, pero los proxies rotos no son la razón. El proxy está roto, debería arreglarse. –
Definitivamente OK:
GET /orders/view/client_id/23 or
GET /orders/view/?client_id=23
También OK:
GET /orders/view/23 or
yo creo que esto estaría bien, también :
POST /orders/view
(custom HTTP header) CLIENT_ID: 23
REST-ful La respuesta POST debe ser un HTTP 303 con un encabezado de ubicación establecido en algo como "/ orders/view/23". –
Solo usaría un encabezado personalizado cuando no haya otra manera de pasar información por estándar o convención. Darren102 está explicando la forma típica de pasar ese valor. Tu Api será mucho más amigable al usar versos de patrones típicos usando encabezados personalizados. Esto no quiere decir que no tendrás un caso para usarlos, solo que deberían ser el último recurso y algo que las especificaciones de HTTP ya no manejan.
Totalmente de acuerdo ... nunca reinvente la rueda si hay una forma estándar de realizar una tarea. –
¿Cuándo utiliza ... los encabezados HTTP en la parte de solicitud de una API REST?
Autenticación: GUID, la autenticación básica, fichas personalizadas, etc., por ejemplo, Basic Authentication with a Guid token for REST api instead of username/password
Si usted se involucra, de paso, fichas u otra información de autenticación similar entre los dominios cubiertos por otras normas de seguridad PCI-DSS o también puede tener que enterrar los parámetros porque algunas reglamentaciones exigen explícitamente que los elementos de autenticación se queden fuera de las URL que podrían reproducirse trivialmente (a partir de historiales del navegador, registros de proxy, etc.).
encabezados personalizados tienen las siguientes ventajas:
también pueden ser eliminados/filtrados silenciosamente por proxies – fusi
puede utilizar encabezados personalizados para incluir más información sobre una solicitud contras parcialmente procesados idering que Enveloping no es una buena práctica. Los encabezados son secure.
¡Gracias por una respuesta tan completa! ¿Seguirías usando el X-User para una API móvil donde el riesgo de tener un proxy malvado (que se deshace del encabezado) todavía es alto? –
No, el uso de X-User que mencioné se encuentra en las conexiones de sistema a sistema donde el sistema actúa en nombre de un tercero. Por ejemplo, el Usuario U habla con el Servidor A. El Servidor A presenta las credenciales al Servidor B con un encabezado X-Usuario para decir "Usar mis credenciales para verificar que estoy autorizado a realizar esta acción en nombre del Usuario U". Esto aparece en Arquitecturas Orientadas a Servicios, y generalmente estás usando HTTPS. Una plataforma móvil casi siempre debe ser el propio Usuario que actúa, y usa las credenciales de primera persona apropiadas para la transacción. – Nialscorva
El tercer párrafo es una de las respuestas más informativas que he leído en SO ;-) – Alistair77