How bad is using @POST to retrieve data?

Question

I am currently using the @POST web service to retrieve data. My idea at the beginning was to pass a parameter map. Then my function, on the server side, will take care of reading the necessary parameters on the map and returning the answer. This is done so that there are not a large number of functions that are almost identical on the server side.

But if I understood correctly, @POST should be used to create content.

So my question is: is this a big programming error for using @POST to retrieve data? Is it better to create 1 web service for one use case, even if there is a lot of it?

Thanks. Romny.

Answer 1

POST is used to say that you are sending data. GET requests can be bookmarked, POST not. Before single-page web applications appeared, we used post-redirect-get to receive data and display a bookmarkable page.

If you use POST to retrieve data, then web caching does not work, since the caching code does not cache POSTS, it expects POST to mean that it should invalidate its cache. If you split your services according to usage scenarios and used GET, then you could cache responses like Squid .

You may not need to implement caching right now, but it would be nice to leave the option open. Bringing your services in line with the requirements means that you can take advantage of existing tools and infrastructure (which is an advantage of REST).

Answer 2

doGet(); 

Called by the server (via the service method) so that the servlet can process the GET request.

 doPost() 

Called by the server (via the service method) so that the servlet can process the POST request.

No problem with them. Both will process your request.