This was very often in the past center of discussion, whether to use GET
or POST
for searchin.
If you are making for example geospatial request, both values are needed (lat and long). If you do it with GET
, you cannot really annotate in openapi that both fields should be dependent on each other - the whole group lat/lon/distance required if one of them set. However there are some opened tickets that could solve these use cases by defining so called fragments, but I dont believe it will be standardized in OpenAPI anytime soon.
Is it really a bad thing to use POST in such cases? From my understanding, POST is used when data is mutated, however it gives us:
- ++ ability to do validate very soon, if all parameters of specific search request are valid and not in controller/service layer
- ++ makes URI more readable (can be used with along filtering)
- -- not able to save it in bookmarks
- -- for testing you need Postman/curl/...
So basically I would have something like this:
POST /stores?country=US
{
"nearLocation": { "lat": 10, "lon": 10, "radius": "10km" }
}
instead of
GET /stores?country=US&lat=10&lon=10&radius=10km
which would require to validate the fields in controller and could not be defined in the openapi file.
What do you think, is it really a bad practice to move some fields to POST? I think we should differentiate between filtering and searching. You can filter enums, strings etc. and you can search with geospatial requests, date range requests where the comparator is not just equal
. Am I thinking right?