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...