Hemos establecido lo siguiente, utilizando OAuth 2 (que es mucho más preferible que OAuth 1). En particular, estamos usando el flujo resource owner password credentials. En cuanto a la forma de integrarlo en nuestro servicio REST, aquí está la idea:
- El recurso inicial, cuando es golpeado por un usuario no autorizado, devuelve un 401. El cuerpo de la 401 contiene un único enlace, con
rel=oauth2-token
. (La forma en que señaliza los enlaces depende de su tipo de medio; estamos usando HAL, pero puede usar incluso el encabezado Link
.)
- Después de que el usuario se autentique, regresa al recurso inicial, enviando en su encabezado
Authorization
el titular token devuelto del proceso OAuth 2. En este punto, devolvemos un 200, con todos los enlaces normales disponibles.
No exponemos la creación de cuentas, pero si quisiera hacerlo, lo haría con otro enlace disponible para usuarios no autorizados en el recurso inicial. Ese enlace tendría un rel
personalizado, ya que es específico de su aplicación, p. rel=http://rels.myapi.com/users
Un buen diseño RESTful indicaría que el enlace con este rel
apunta a, p. Ej. http://myapi.com/users
, y que los consumidores de la API hacen un POST
a ese punto final, que les devuelve el nuevo recurso de usuario con un encabezado Location
apuntando al recurso de usuario recién creado, por ejemplo, http://myapi.com/users/username
. (Los propios recursos del usuario serían por supuesto otro rel
, distinguiendo entre el recurso de usuario singular y el recurso de colección plural de usuarios.)