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


¿Cuándo usa 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 lugar de

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

76
2018-02-06 23:49


origen


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, para parametrizar el acceso al recurso. Esto especialmente entra en juego con publicaciones y búsquedas: /orders/find?q=blahblah&sort=foo. Hay una delgada línea 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 RE representa una Transferencia de estado (para modificar la mnemotécnica), los encabezados personalizados solo deben usarse para elementos que no involucran el nombre del recurso (la url), el estado del recurso (el cuerpo) o parámetros directamente. afectando el 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 necesitará. 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 use 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.


87
2018-02-07 00:12



Solo usaría un encabezado personalizado cuando no haya otra forma de pasar información por estándar o por 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.


5
2018-02-06 23:56



Los encabezados personalizados tienen las siguientes ventajas:

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

4
2017-12-09 11:02



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

GET / orders / view / client / 23


3
2018-02-06 23:53



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

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

Si se involucra en el envío de tokens u otra información parecida a la autenticación entre dominios cubiertos por PCI-DSS u otras reglas de seguridad, también puede tener que enterrar parámetros porque algunas reglamentaciones exigen explícitamente que los elementos de autenticación se queden fuera de las URL que puedan reproducirse trivialmente (desde historial del navegador, registros de proxy, etc.).


3
2018-06-23 19:26



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

GET /orders/view/23

No usar los encabezados personalizados y, por lo tanto, la vista posterior a 23 supone 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.


2
2018-02-06 23:52



Definitivamente bien:

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

También está bien:

GET /orders/view/23 or 

Yo pensaría que esto también estaría bien:

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

1
2018-02-06 23:54



Puede usar encabezados personalizados para incluir más información sobre una solicitud parcialmente procesada teniendo en cuenta que Envolvente no es una buena práctica. Los encabezados son seguro.


0
2018-03-04 12:37