CODEWITHSUNDEEP
apiresthttp
Ghassan Barghouti
Ghassan Barghouti

Reputation: 1

Should I use GET or POST if getting idempotent information but with parameters that are not meant to be in URL

I have an API that gets a Credit Card number when you supply a reference id. The reference id is considered sensitive data, so my understanding that it shouldn't show up in the URL, and instead needs to be defined in JSON body while the protocol is HTTPs for encryption.

Now should the request be a GET which sounds more natural when reading it, yet looks odd when attaching a JSON body to it. Or should it be POST were it makes sense to have a JSON body, yet sounds odd when reading it, and also the request in itself is idempotent.

Upvotes: 0

Views: 332

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57279

A payload within a GET request message has no defined semantics -- RFC 7231

If you must pass information to the server in the payload of the request, then GET isn't a valid option.

On the other hand

POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.” -- Fielding, 2009

In other words, we use POST if none of the other registered methods have appropriate semantics and we don't want to extend HTTP with our own method-token.

should it be POST were it makes sense to have a JSON body, yet sounds odd when reading it, and also the request in itself is idempotent.

It's not ideal - you have a request where the intended semantics are idempotent, but no effective way to communicate that to general purpose components.

What you can sometimes do, is use a request with a body to create a new resource, and then use GET with the identifier of the new resource. That keeps the sensitive information out of the logs, while still giving you safe semantics, but at the cost of an extra round trip and some complexity

POST /foo
Content-Type: application/json

{ "CreditCardNumber" : "0000-0000-0000-0000" }


201 Created
Location: /4d49cad6-4165-472d-ad61-c91160fdd06c
Content-Location: /4d49cad6-4165-472d-ad61-c91160fdd06c

Here, Location tells a general purpose client where the new page has been created, and Content-Location tells a general purpose client that the contents of this message is a copy of the new page.

If the client wants to check that page later for an update, a simple GET request will work

GET /4d49cad6-4165-472d-ad61-c91160fdd06c

So the URI never has the credit card number, but instead has a token that can unlock the credit card number from some secure store at the server.

In effect, /4d49cad6-4165-472d-ad61-c91160fdd06c is a web page about credit card number 0000-0000-0000-0000.

But there's extra song and dance when the client doesn't remember the unique identifier for that web page, and has to use POST to ask where it is again.

Upvotes: 2

Related Questions