There is a java, REST API based web application which uses HTTP POST request to search a user specific parameters including wildcards. The same application uses GET request to get specific resources using Ids. Recently an architect came to an idea of using that same POST request to load specific resources using IDs instead of using typical GET request which has a pattern GET some/resource/by/{id}. Literally the whole idea is to use that same POST request which is used for a search, to load resources by Ids. Is it a bad practice? I would like to hear your thoughts, ideas and conclusions.
Yes, using an HTTP POST request to retrieve resources by ID, especially when that resource can be retrieved safely via GET, is generally considered bad practice in RESTful design.
Here’s a breakdown of why and when you might deviate:
Violates HTTP Semantics
GET is safe and idempotent: It doesn't change server state and can be cached, bookmarked, and repeated safely.
POST is not safe and not idempotent by definition: It's meant to submit data that changes server state (e.g., create/update resources).
Using POST to fetch a resource by ID misleads both clients and intermediaries (e.g., caches, proxies).
Hurts Cacheability and Performance
GET responses can be cached by browsers and CDNs.
POST responses are rarely cached by default, which means repeated calls cost server resources unnecessarily.
Breaks RESTful Conventions
REST emphasizes using the appropriate HTTP methods for resource operations.
Mapping POST /some/resource/by/{id} for a pure lookup is confusing and unstandardized.
Other developers and tools (Swagger/OpenAPI, Postman, etc.) are expected GET for retrieval.
For large or complex queries (e.g., hundreds of filters, multiple IDs), POST is acceptable due to:
Query string length limitations in GET.
Better body structure for expressing complex parameters (e.g., JSON).
Use case: POST /users/search with body { "ids": [1,2,3,4], "status": "active" }.
So you should decide on your situation...