I'm building a REST API for a personal project, and one of my handlers is meant to retrieve a set of data from a large SQLite table. The frontend is divided into pages, showing limited results, which the user can switch through to sift through the data.
Each time the user switches pages (or changes sorting filters), a new HTTPRequest is executed.
The HTTP Request contains the following parameters to tune the result set:
{
resPerPage, // results per page (10, 20, 30, etc.)
thisPage, // user's current page
orderBy, // column to order data with
orderByDirection // ASC or DESC
}
Right now, this data is all included in the body of a POST HTTPRequest.
I'd like to switch it to a GET request to follow conventions. However, according to the HTTP Specs, GET requests shouldn't include a body.
I know how to use headers instead to cover this data, but I question if that's the "best practice" solution to this problem.
Here are my ideas:
A. Keep the POST request type and just keep it in the body.
B. Switch to GET, and make each parameter it's own unique header.
C. Switch to GET, and make one header that contains a JSON object with the parameters.
D. Switch to GET, and use query parameters to pass the data.
Which Idea should I go with to follow best practices? Or something else entirely?
I'm leaning towards Idea D, since none of the data here is sensitive.
This API will only be used by my website. Nobody else will be interfacing with it, so it's nothing critical. Just trying to build good habits.