¿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
¿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:
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.
Los encabezados personalizados tienen las siguientes ventajas:
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.
¿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.).
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.
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
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
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 .