Consider making /api/predict a GET operation instead of POST
kevinsteger opened this issue · 3 comments
That would be consistent with other API standards. We are not adding anything with the predict operation. The /api/learn however does add new information and should remain POST.
In production we lock down services this way using NGINX and only allow certain services to accept only HTTP GET requests. For example certain Elasticsearch nodes can only process HTTP GET thus making them read-only. This is a much needed security model to harden a production environment. Current configuration of Chantilly would not allow this.
FYI this is how you do that in a server block on NGINX:
{ ... limit_except GET { deny all; } ... }
Sure that seems fair, I actually hesitated when I implement it. But is it okay, semantically, to have a GET route to require a body?
We are not adding anything with the predict operation.
If there is an id field in the body, the features and the prediction will be stored, which feels like a POST request, no?
I'm OK either way. We can always just change the request type on the fly as we proxy.
Okay I'll keep it the way it is then. I didn't know you could do that :). Are there any other changes you would like to see happen?