API REST: encabezados HTTP personalizados frente a parámetros de URL


96

¿Cuándo usas encabezados HTTP personalizados en la parte de solicitud de una API REST?

Ejemplo:

Alguna vez usarías

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

en vez de

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

Respuestas:


123

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, parametrizar el acceso al recurso. Esto es especialmente entra en juego con los postes y las búsquedas: /orders/find?q=blahblah&sort=foo. Hay una línea muy fina entre parámetros y sub-recursos: /orders/view/client/23/active versus /orders/view/client/23?show=active . Recomiendo el estilo del sub-recurso y los parámetros de reserva para las búsquedas.

Dado que cada extremo representa una transferencia de estado (para modificar el mnemónico), los encabezados personalizados solo deben usarse para cosas que no involucren el nombre del recurso (la URL), el estado del recurso (el cuerpo) o los parámetros directamente afectando el recurso (parámetros). Eso deja metadatos verdaderos sobre la solicitud de encabezados personalizados.

HTTP tiene una amplia selección de encabezados que cubren casi todo lo que necesita. Donde he visto aparecer encabezados personalizados es en un sistema a solicitud del sistema que opera en nombre de un usuario. El sistema de 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 receptor valida que las credenciales del sistema están autorizadas para actuar en nombre del usuario, luego valida que el usuario está autorizado para realizar la acción.


¡Gracias por una respuesta tan completa! ¿Seguiría utilizando X-User para una API móvil donde el riesgo de tener un proxy maligno (que elimine el encabezado) sigue siendo alto?
Vasile Cotovanu

1
No, el uso de X-User que mencioné es en 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-User para decir "Use mis credenciales para verificar que estoy autorizado para realizar esta acción en nombre del usuario U". Esto aparece en arquitecturas orientadas a servicios y, por lo general, está utilizando HTTPS. Una plataforma móvil casi siempre debería ser el propio Usuario actuando y utilizar las credenciales de primera persona adecuadas para la transacción.
Nialscorva

7
El tercer párrafo es una de las respuestas más informativas que he leído en SO ;-)
Alistair77

1
@Nialscorva ¡Gran explicación! ¿Qué pasa si me gustaría que el usuario interactúe con mi API a través de un contenedor autorizado (como mi aplicación móvil)? Lo que estoy haciendo ahora es que mi aplicación móvil no está autorizada para realizar ninguna acción por sí misma ni el usuario final. Ambas credenciales deben estar presentes si el usuario está dispuesto a realizar una acción.
bolbol

6

Los encabezados personalizados tienen las siguientes ventajas:

  • Se puede leer fácilmente mediante herramientas / scripts de red (autenticación, metainformación, ...)
  • Mantiene las URL libres de elementos de seguridad (más seguras, no en las cachés del navegador / proxy)
  • Mantiene las URL más limpias: permite un mejor almacenamiento en caché de recursos

también pueden ser eliminados / filtrados silenciosamente por proxies
fusi

@fusi buen punto ... aquí está el tema al respecto: stackoverflow.com/questions/20820572/…
Christophe Roussy

5

Solo usaría un encabezado personalizado cuando no haya otra forma de pasar información por estándar o convención. Darren102 está explicando la forma típica de pasar ese valor. Su Api será mucho más amigable al usar patrones típicos verso usando encabezados personalizados. Eso no quiere decir que no tendrá un caso para usarlos, solo que deberían ser el último recurso y algo que aún no esté manejado por la especificación HTTP.


Totalmente de acuerdo ... nunca reinvente la rueda si existe una forma estándar de realizar una tarea.
Alessandro Santini

5

¿Cuándo usas ... encabezados HTTP en la parte de solicitud de una API REST?

Autenticación: GUID, autenticación básica, tokens personalizados, etc., por ejemplo, autenticación básica con un token Guid para la API REST en lugar de nombre de usuario / contraseña

Si se involucra en el paso de tokens u otra información similar a la autenticación entre dominios cubiertos por PCI-DSS u otras reglas de seguridad, es posible que también deba ocultar los parámetros porque algunas regulaciones requieren explícitamente que los elementos de autenticación se mantengan fuera de las URL que podrían reproducirse trivialmente (de historiales del navegador, registros de proxy, etc.).


1

No existe un estándar para REST, sin embargo, la forma aceptada sería

GET /orders/view/23

Al no usar los encabezados personalizados y, por lo tanto, la vista posterior a 23 asume que es la identificación, por lo tanto, tendría una función que toma la identificación y, por lo tanto, produce solo esa información.


1

No usaría encabezados personalizados ya que no sabe si algún proxy los pasará. Basado en URL es el camino a seguir.

OBTENER / pedidos / ver / cliente / 23


1
Tampoco recomendaría encabezados personalizados, pero los proxies rotos no son la razón. Si el proxy está roto, debería arreglarse.
Julian Reschke

1

Definitivamente bien:

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

También está bien:

GET /orders/view/23 or 

Creo que esto también estaría bien:

POST /orders/view 
(custom HTTP header) CLIENT_ID: 23

La respuesta REST-ful POST debe ser un HTTP 303 con el encabezado Location configurado en algo como "/ orders / view / 23".
Rich Remer

0

Puede usar encabezados personalizados para incluir más información sobre una solicitud parcialmente procesada, considerando que el envolvente no es una buena práctica. Los encabezados son seguros .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.