Skip to main content

"Dushnylo" Series: The Trouble with GET: Real-World REST API Challenges

Have you ever seen a fully implemented, truly and absolutely by-the-books REST API? With all the correct HTTP methods, status codes, and the perfect design?
No? Me neither. And you might ask — why not? After all, it's supposed to be easy, right?

Well, yes — technically, it is easy. But in real life, you always run into edge cases.

Let’s take a simple example. According to REST principles, if you want to retrieve data, you should use the GET method. Simple and elegant, and documented everywhere. But then the question arises: how do you pass parameters in a GET request?

Answer: via URL path or query parameters.

But as you already know, there’s a limit to how much you can fit into a URL — usually around 2048 characters. That’s fine for small, basic queries. But what about advanced searches? You want to pass dozens of filters, custom ordering, maybe even a list of IDs to fetch. Sometimes it’s a list of GUIDs — and not just one or two, but hundreds.

In these cases, GET simply doesn’t work. The URL becomes too long and breaks. So what’s the alternative?

The common solution is to switch to a POST request. It works perfectly — you can pass a large JSON body with all your parameters.
But wait… according to REST, POST is for creating data, not retrieving it.

So now you're stuck:

  • You can't use GET because of technical limitations.

  • You shouldn’t use POST because it goes against the philosophy of REST.

What now?

This is one of those grey zones where you have to balance between theory and practicality. In my experience, I’ve had to use POST for advanced search endpoints. I’ve seen APIs that even created a special route like /search or /query and used POST there — clearly breaking REST rules, but solving real-world problems.

If you’ve faced this too, I’d love to hear how you handled it.
Do you break the rules for the sake of usability? Or do you find creative workarounds to stay within REST boundaries?

Share your thoughts and use cases — let’s talk about the real REST API, not just the one in textbooks.

Labels:

Comments

Post a Comment

Popular posts from this blog

Microsoft Azure Well-Architected Framework - Maturity models

The Azure Well-Architected Framework has always been a great way to assess and review workloads. But with the recent updates—especially the introduction of maturity levels —it’s becoming much more than just a checklist. 💡 It’s evolving into a concept. Not only can teams review their architecture, but they can now score, track progress, and continuously improve . The maturity model provides clear stages—from establishing a solid foundation to achieving future-proof agility—making it easier to understand where you are today and where you should aim tomorrow. Why is this important? ✅ It transforms reviews into a roadmap for growth ✅ It allows measurable scoring of architecture maturity ✅ It pushes teams to focus not only on compliance, but also on resilience, agility, and future-readiness Each update makes the Azure Well-Architected Framework better and stronger —helping organizations align technology decisions with long-term business success. 👉 In my view, this is the right dire...
Post a Comment
Read more

Coinbase x402 is great option for paymant per request!

  🚀 What is Coinbase x402? x402 is a new open payment protocol built by Coinbase that revives the long-forgotten HTTP 402 “Payment Required” status and turns it into a modern, internet-native payment layer . Using stablecoins (such as USDC ) directly over HTTP, x402 allows services: APIs, websites, or digital content platforms to charge per request. At the same time,  clients (including AI agents and automated systems ) can pay programmatically , without accounts, subscriptions, or human interaction. In simple terms: request → pay → get response , all at the protocol level. How It Works (Simplified) A client requests a protected resource (API, data, article, service). The server responds with HTTP 402 Payment Required , including payment instructions. The client (app or AI agent) generates a payment transaction using its wallet. The client resends the request with payment details included in HTTP headers. The server verifies the payment and immediately ret...
Post a Comment
Read more

Microsoft Azure Well-Architected Framework - Reliability

Reliability is a foundational pillar when building resilient systems, especially for critical components. Outages and malfunctions pose serious risks to any workload, so a truly reliable system must be designed to detect, withstand, and recover from failures within an acceptable timeframe. It must ensure continued functionality and maintain availability so that users can access services as expected, both in terms of uptime and quality. 🔧 Aligned with Azure’s Reliability Checklist Keep it simple and efficient Strive for a solution that meets requirements without unnecessary complexity—simplicity simplifies reliability Identify and prioritize flows Map out user and system flows, assess their criticality, and focus engineering efforts on those with the highest business impact Conduct failure mode analysis (FMA) Investigate every dependency and component with a methodical FMA to uncover weak points, and design mitigation strategies accordingly Define clear reliability and r...
Post a Comment
Read more