I need to update an existing REST API method that returns available subscription plan information. Slightly fictionalized, it looks like this:
GET /api/available-plans/{provider-id}
...where {provider-id} is something like "google" or "apple".
The problem that I'm trying to solve now is that sometimes the available plans, or some property of them, depend on some additional information, like which plans the user has previously subscribed to. In the case of Apple subscriptions, I would like to send along the user's current bundle receipt for analysis on the server.
The problem is that the receipt data can be very large -- at least 10s of K, just for one of my test users, so maybe 100K or more for some users. This post on Stack Overflow from 2018 says the maximum safe query string length is 2048 characters, and this post says the overall length of a URL should be 2000-8000 characters. So it appears I can't safely put this into the URL.
One option might be to put it into the body, but my understanding is that this goes against REST principles in a GET request.
A rule-breaking option could be just to POST it instead, but it seems like that really goes against the principles of REST.
I suppose I could POST the data somewhere, get a URL, and then send along the URL with my GET request, but then I have to make two calls and also worry about saving the data and cleaning it up.
Is there some other option for a case like mine?
TL;DR: use POST.
A rule-breaking option could be just to POST it instead, but it seems like that really goes against the principles of REST.
What you are faced with is a tension: you'd like to send a request that general purpose components would recognize as safe, but their isn't a registered method that has the semantics you need (in this case, safe AND with a semantically significant request body).
And in HTTP, the answer to "there isn't a method that has the semantics I need" is to use POST.
The thing that you want (maybe) is HTTP QUERY -- you could look at the draft specification, and determine if the semantics meet your needs. And if it does, you have to decide whether you want to take on the risks of implementing your API based on an expired draft of a specification.