What is the best practice for sending a large array of strings to an API

Question

I'm building a simple app that is a client web application and an API behind it. I'm combining two third-party APIs, one needs to be called from my client application (for ease of authentication) and one needs to be called by the server.

The data I receive from my first API is a list of strings - it will be between 0 and 150 items long, each string is an unknown length. Each one of these items needs to be passed to my server - either as individual elements (preferred) or as a serialised string. My endpoint will always return a single object, regardless of how many items are passed to it.

What is the most semantic way of passing this data to my API?

It's not really a GET request as the returned object is dynamic, and I'm concerned about the URL length limits (discussed here) given that I don't know what these strings will look like.

POST also feels incorrect as I'm not going to storing what is sent to me, though this would allow me to send the data in the body of the request and not worry about the size.

Perhaps I shouldn't worry so much about semantics and just do what works, but I'm interested in opinions on the best, or 'proper', way to design my API here.

Answer 1

It's not really a GET request as the returned object is dynamic

Not really relevant. "Resources", the things identified by uniform resource identifiers, are not fixed in time

Some resources are static in the sense that, when examined at any time after their creation, they always correspond to the same value set. Others have a high degree of variance in their value over time. The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another -- Fielding, 2000.

You wrote:

I'm concerned about the URL length limits

That's a legitimate problem.

Fundamentally, HTTP really didn't evolve with the use case "safe operation that takes a query document as an argument" as part of its primary supported set.

The closest you can get to "answer a question about my document" is probably "copy my document; answer a question about your copy of my document". While you can compress away the second part of that by inlining it into your response, the first part of the request is inherently unsafe, so you need to be looking at POST/PUT/PATCH.

In some cases, you can find that a method has been registered that fits your use case, and then you are good to go. And of course defining your own method is always an option.

I shouldn't worry so much about semantics and just do what works

The good news is that POST "just works" and has very flexible and forgiving semantics.