9

I am implementing REST API using the following technologies/approaches:

I want to implement authentication endpoint, it should receive username and password in POST request in JSONAPI format and return JWT token in JSONAPI format. But I see there are some contradictions that does not allow me to be 100% RESTful:

Let's name endpoint /tokens, because it actually creates tokens. Response would be also resource of type tokens, e.g:

{
  "data": {
    "type": "tokens",
    "attributes": {
      "value": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjEifQ.ivJ5P23wqVo3w31flg3aOu7er--Ijght_RrBf_MuqsU",
    }
  }
}

But how about request? username and password are properties of user, but they should be sent to /tokens endpoint. If I send users resource to /tokens endpoint it does not make much sense.

Is there a way around for this, to follow JSONAPI and keep API meaningful?

Sergey Potapov
  • 2,900
  • 1
  • 20
  • 37
  • What I do in these cases is having a session object or entity which is the one containing the properties you mention and I wouldn't care they're from a user because the user is the one authenticating. In any case, JSONAPI and REST are good guides to follow but apply your style when in need. – Francisco Quintero Oct 24 '18 at 20:33

2 Answers2

5

If I send users resource to /tokens endpoint it does not make much sense.

Why not? REST does not impose that you only send users to a user resource. Sure, when you CRUD operations on a user resource you'll do this via the user resource endpoint.

But to generate a token, it's totally reasonable to send a user resource to the token endpoint.

MvdD
  • 17,926
  • 5
  • 51
  • 83
  • Hi, thanks for the reply. > REST does not impose that you only send users to a user resource. REST does not, but REST API specification does. That's the problem. – Sergey Potapov Nov 30 '18 at 18:12
2

You could also supply the user credentials via an HTTP Authorization header, or as part of the toplevel meta property of the JSON payload.

beauby
  • 519
  • 2
  • 11