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:
fuente
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.
fuente
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.).
fuente
No existe un estándar para REST, sin embargo, la forma aceptada sería
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.
fuente
No usaría encabezados personalizados ya que no sabe si algún proxy los pasará. Basado en URL es el camino a seguir.
fuente
Definitivamente bien:
También está bien:
Creo que esto también estaría bien:
fuente
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 .
fuente