I’ve built an API using Spring that lets clients fetch objects by sending a list of IDs. Instead of using GET with a bunch of IDs in the URL, I’m using POST with a ProductRequest object in the body. This way, I can include extra parameters to customize the output.
The API returns a JSON list of objects using @ResponseBody. I’m using @RequestBody to receive the request data.
I know this isn’t exactly following REST principles, since POST is meant for creating new stuff. But it seems more practical than cramming everything into the URL.
Is this still okay? Can I call it RESTful? Or am I breaking too many rules here? I’m not sure if I should stick to the GET method or if my current setup is fine.
@PostMapping("/products")
public List<Product> getProducts(@RequestBody ProductRequest request) {
// Process request and return products
}
What do you think? Is this a reasonable approach or should I change it?
While your approach isn’t strictly RESTful, it’s a pragmatic solution for handling complex queries. REST guidelines suggest using GET for retrieval, but they’re not hard rules. Your method allows for more flexibility in query parameters and avoids URL length limitations.
However, this design choice may surprise developers familiar with REST conventions. To mitigate confusion, consider naming your endpoint something like ‘/products/search’ to indicate its purpose. Also, thoroughly document your API to explain the rationale behind using POST for retrieval.
Ultimately, the best API design balances adherence to standards with practical considerations. If this approach meets your needs and is well-documented, it’s a reasonable compromise.
I’ve been in your shoes before, and I can tell you from experience that sometimes you need to bend the rules a bit to get things done efficiently. While using POST for data retrieval isn’t strictly RESTful, it can be a practical solution for complex queries.
In my previous project, we faced similar challenges with long lists of IDs and custom parameters. We ended up using a hybrid approach - GET for simple queries and POST for more complex ones. This worked well for us and our API consumers.
One thing I’d suggest is to clearly name your endpoint to reflect its purpose, like ‘/products/bulk-fetch’ or ‘/products/advanced-search’. This helps set the right expectations for other developers using your API.
Also, make sure to document your design decisions thoroughly. Explain why you chose this approach and what benefits it brings. This transparency goes a long way in preventing confusion and pushback from other developers.
Remember, while following standards is important, solving real-world problems efficiently should be your primary goal. As long as your API is consistent, well-documented, and meets your specific needs, you’re on the right track.
nah, that’s not really RESTful. POST is for creating stuff, not fetching data. but hey, if it works for ur use case, who cares? sometimes practicality trumps following rules to a T. just be aware some devs might get confused by the non-standard approach. maybe document it clearly?