CODEWITHSUNDEEP
rest
Rafa Acioly
Rafa Acioly

Reputation: 636

What HTTP method should i use when i need to pass a lot of data to a single endpoint?

Currently i've asking if the current HTTP method that i'm using on my rest api is the correct one to the occasion, my endpoint need a lot of data to "match" a query, so i've made a POST endpoint where the user can send a json with the parameters, e.g:

{
    "product_id": 1
    "partner": 99,
    "category": [{
        "id": 8,
        "subcategories": [
            {"id": "x"}, {"id": "y"}
        ]
    }]
    "brands": ["apple", "samsung"]
}

Note that brands and category are a list.

Reading the mozzila page about http methods i found:

The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.

My POST endpoint does not take any effect on my server/database so in theory i'm using it wrong(?), but if i use a GET request how can i make it more "readable" and how can i manage lists on this method?

Upvotes: 1

Views: 1157

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57239

What HTTP method should i use when i need to pass a lot of data to a single endpoint?

From RFC 7230

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

That effectively limits the amount of information you can encode into the target-uri. Your limit in practice may be lower still if you have to support clients or intermediaries that don't follow this recommendation.

If the server needs the information, and you cannot encode it into the URI, then you are basically stuck with encoding it into the message-body; which in turn means that GET -- however otherwise suitable the semantics might be for your setting -- is out of the picture:

A payload within a GET request message has no defined semantics

So that's that - you are stuck with POST, and you lose safe semantics, idempotent semantics, and caching.

A possible alternative to consider is creating a resource which the client can later GET to retrieve the current representation of the matches. That doesn't make things any better for the first adhoc query, but it does give you nicer semantics for repeat queries.

You might, for example, copy the message-body into an document store, and encode the key to the document store (for example, a hash of the document) into the URI to be used by the client in subsequent GETs.

For cases where the boilerplate of the JSON document is large, and the encoding of the variation small, you might consider a family of resources that encode the variations into the URI. In effect, the variation is extracted from the URI and applied to the server's copy of the template, and then the fully reconstituted JSON document is used to achieve... whatever.

Upvotes: 2

RotatingPieces
RotatingPieces

Reputation: 413

You should be using a POST anyways. With Get you can only "upload" data via URL parameters or HTTP Headers. Both are unsuitable for structured data like yours. Do use POST even though no "change" happens on the server.

Upvotes: -1

Related Questions