REST Get Solicitudes, Verbos y Apikey

Question

Quiero crear un servidor de descanso API flexible. Permitiré que los clientes se autenticen usando HTTP o un Apikey.

Mi pregunta es: ¿Cuál es la forma correcta de agregar el apikey a una solicitud GET? Mi problema es que el apikey contamina la URL.

Me imagino algo como esto:/libro/1/apikey/s4cr4t!

Answer 1

En mi opinión, solo debes usar el encabezado de autorización. Para eso está ahí.

Ponerlo en la URL es una mala idea porque:

a) Como dijiste, contamina la URL
b) Si decide ir a SSL para obtener seguridad, la API aún aparecerá en archivos de registro
c) Los cachés terminarán creando múltiples copias de la misma representación, una para cada clave API.

Para obtener más información sobre la creación de su propio esquema de autorización, vaya aquí.

Answer 2

Se pueden aprobar las credenciales utilizando el Authorization encabezamiento:

GET http://domain.com:/book/1
Authorization: apikey="s4cr4t"

Answer 3

Todo depende de qué tan lejos quieras llegar, pero la mecánica permanece igual:

Contexto

El objetivo es identificar al cliente con cierto nivel de seguridad. (Nota: la seguridad es otra discusión detallada). Recuerde que si las "características" de REST deben ser apátridas: eso significa que no hay estado de sesión en el servidor, excepto los recursos. Para mantener al cliente sin estado, debe suministrar en cada solicitud suficiente información para que la solicitud sea independiente. Debe darle al servidor una forma de identificar al cliente, como un nombre de usuario/contraseña, clave API o token.

Tienes varias opciones para hacer esto, así que aquí hay algunas:

Agregue los encabezados HTTP para identificar al cliente

Aquí se puede usar el encabezado de autorización y enviarlo con cada solicitud. Existen varios esquemas de autenticación, pero se adhieren a los estándar como Autenticación básica. Aquí probablemente te quedarías con SSL. El proceso de autenticación genera un tipo de token si lo desea.

También puedes hacer uso de una cookie. La cookie debe contener sin información Excepto que es un "puntero o clave" para un recurso de sesión con estado en su servidor (nota: Senta un recurso que es "REST-Legal"). Puede crear este recurso haciendo una PUT (+Info) con Respuesta 200 OK o POST (+Info) con una respuesta de 201 creada y ubicación: /sesiones /123334. La sesión puede ser validada por el servidor, como el tiempo de espera, la dirección IP del cliente válida, la clave API, etc.

Con el método anterior, también puede definir un encabezado de clientes como API-Key: xxxx. Pero luego te limitas al cliente especial. Set-Cookie son encabezados "bien conocidos", por lo que el navegador los manejará de manera transparente. El proceso de autenticación se puede realizar siguiendo enlaces y completando formularios (PUT + POST) para autenticar (crear recursos de sesión).

Codificar un identificador en el contenido

Aquí eres libre de hacer lo que quieres también. Simplemente agregue un campo/token/ID a su contenido y deje que el servidor lo verifique.

Una API RESTful realiza flujo de aplicación resolviendo enlaces. Ver también Odioas y Palabras de Fielding. Esto también se aplica cuando tiene un proceso separado de iniciar sesión en la aplicación.

No codifique ningún dato en los URI. (Información fuera de la banda)