GET vs POST when exposing machine learning model predictions using a REST API

Question

So the recommendations for using GET vs POST in a REST API that I've read on stack overflow are geared almost exclusively toward CRUD operations involving a database.

However if you are simply writing the API to expose a machine learning model to serve predictions, most of the examples I've seen online use POST requests without explaining why they use it as opposed to a GET request.

From my perspective a GET request can serve the same purpose because if my prediction method requires some sort of data that will never be placed in the URL (like a json string), I can send it in the body of the GET request the same way I can with a POST request. I'm also not modifying anything on the server with the GET request.

Regarding idempotency, the model prediction should return the same result if a request containing the same input parameters is sent multiple times, making GET in this case idempotent.

So my question is, in this specific scenario - exposing machine learning models, or other functionality not involving any database - is there any reason why I would use a POST request instead of a GET?

Or could you use these interchangeably in this scenario without any difference?

Answer 1

if my prediction method requires some sort of data that will never be placed in the URL (like a json string), I can send it in the body of the GET request the same way I can with a POST request

That is wrong. While you can technically do so, you are not supposed to do so and many implementations will not allow you to receive it, send it, or just ignore (swallow) it.

If you want to send a body that influences the outcome of the request, you need to find another http verb, GET is not meant to do that.

That is why most people choose POST.

Further reading on the technical aspects of how or why GET requests can or cannot have a body: https://stackoverflow.com/questions/978061/http-get-with-request-body

Answer 2

Functionally yep, you can use get, post, put, or any other http verb you like. The internet won't like you though.

• POST implies a process on the other end that is always in flux as to its state. The output is not presumed to be deterministic, repeatable, or cacheable.
• GET on the other hand implies a level of determinism, repeatability, and cache friendliness. For a given input string/request, its roughly assumed that any repeat request can be served from a cache.

All of the proxies and caches inbetween you and your customer will be geared toward this, and while not all of them will decide to cache/etc... there will likely be one that does, and neither you nor you client will understand why your machine learning model is broken for them.

---

As an aside though standards are written down. You can also find them discussed on many sites like Wikipedia, and Mozilla.

Answer 3

Or could you use these interchangeably in this scenario without any difference?

They cannot be used interchangeably.

Caching is very important to the world wide web; it is one of the architectural constraints of the REST style. General purpose web caches are not going to know that the body of the GET request needs to be treated as part of the cache key, so you are likely to have problems when that general purpose component starts returning previously cached responses.

The key idea is that HTTP isn't a general purpose messaging protocol; it is an application protocol, whose application domain is the transfer of documents over a network. Our API is a facade that makes whatever we are doing (in your case, your machine learning model) look like a 1990s web site.

In REST, we have a uniform interface - everybody understands the same messages the same way; that's what allows us to connect general purpose components together and leverage work that has already been done.

So when you decide that your server should use message semantics that break the semantic constraints of the standard, you are laying the foundation of one of two kinds of failure: either you need REST, and your bespoke changes mean that you aren't going to get inter-op, or REST isn't the appropriate style for your needs.

---

That said, safe-method-with-a-body is a common problem to have; we don't have an standard that supports that idea today, but in late 2020 the HTTP-WG adopted a proposal to develop that standard; you can see the current work in progress.

In the mean time, it is okay to use POST.