I have done some research regarding this, but I haven't found a solid answer for this particular situation.

Let's say I have a route called /information that returns some sensitive data of a specified info_id and only if provided with a valid one_time_code.

I can think to do this in two ways:

1. GET /information?info_id=x&one_time_code=y
2. POST /information
   body: info_id = x, one_time_code = y

Response (this does not change, nor does anything else in the database - the one time code has an expiry - and can be cleared via a different way):

{
    "info_owner_id" : "1234",
    ...
}

From how I understand it the GET approach would seem to be the more RESTful approach, but may not be ideal as the URL with the query strings would get saved in the browser and perhaps results would get cached along the way. Also, the info_id could leak along the way (even if using HTTPS as its in the URL).

However, with the POST approach, nothing is cached and expired codes won't be saved in the browser. However, nothing is created and in fact, the database isn't altered at all so it may not be the most 'logical' approach.

I'm struggling to understand what would be the best practices in this situation, I hope to receive some clarification.

Furthermore, if you think a completely different way is preferable, please let me know. I was thinking to use GET with authentication headers, but my site doesn't have 'users' in its database, but people can save their own info and get access to it with generated links (info_id / one time code sent via email).

CodePudding user response：

If the one time code leaks, is it a problem as it can be used only once? I mean even if you send it on the url, the response will be retrieved and if the hacker wants to reuse it, it won't work...

And in my opinion the most RESTful way would be:

GET /information/{infoId}?oneTimeCode=xxx

or

GET /information/{infoId}/{oneTimeCode}

But it's not really RESTful as it is not stateless, providing you cannot access the same resource twice with the same url.

CodePudding user response：

I would use a GET request. Even if the request was cached in the browser history (I'd use XHR/ajax), getting the one-time code isn't a destructive action and wouldn't really be a danger. As you've mentioned, since nothing is being altered, you should go with a GET request. P.S, All query GET parameters are as secure as the POST body would be with SSL.

CodePudding user response：

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record).

So with your case, people often use get method.

GET /information/{infoId}

With sensitive information, I highly recommend we should hide it anyway, hide it from the eye of user.

So in my opinion, we should put one-time token code in header if you use get, or put it in body if you use post method.

Even if with https, get or post are both secure. I still want to keep it hidden from the eye of user.

Stateless is ideal, but it's hard to reach when the system is quite complex with authentication, timeout, one-time token, ....