Coder Legion - Recent posts tagged rest-api

I Was Tired of Installing API Tools Just to Test One Endpoint — So I Found Something Better

Wed, 03 Jun 2026 18:41:12 +0000

Let me paint you a picture.

It's 11 PM. You're integrating a third-party payment API into your app. The documentation is decent, but something isn't working — you keep getting a 401 Unauthorized back, and you have no idea if it's your token, your headers, or just the universe conspiring against you.

Your options? Fire up Postman (which you haven't opened in three weeks and now wants to update), install Insomnia (if you remember your account password), or try writing a quick curl command in the terminal — knowing full well you'll mess up the escaping on the JSON body and spend another 20 minutes Googling why.

There's a fourth option. One that requires zero installs, zero accounts, and zero patience for setup.

But before we get there — let's actually talk about REST APIs, because if you're new to this world, a lot of it can feel unnecessarily mysterious.

What Even Is a REST API?

Here's the non-textbook version: a REST API is just a way for two systems to talk to each other over the internet using standard web rules.

When you open Instagram and your feed loads — that's your app making an API call to Instagram's servers. When you book a flight and your seat gets confirmed — that's an API call going to the airline's backend. When Slack notifies you of a new message on your phone — you guessed it.

REST stands for Representational State Transfer, which sounds incredibly academic and not particularly useful to know. What matters is the practical part: REST APIs use regular HTTP (the same protocol your browser uses), they deal in resources (think: users, orders, products), and they communicate mostly in JSON — a format that looks like this:

{
  "user": "sadiq",
  "status": "active",
  "plan": "pro"
}

Clean. Human-readable. Easy to work with.

The other thing you need to know is that REST APIs use HTTP methods to express intent:

GET — "Give me something." Fetching a list of users, loading a profile, retrieving an order.
POST — "Create something new." Submitting a form, registering an account, placing an order.
PUT — "Replace this thing entirely." Updating a user's full profile.
PATCH — "Just change this one part." Updating only the email address on a profile.
DELETE — "Get rid of this." Removing a record.

These five methods cover about 99% of what you'll encounter in real-world API work. The other two — HEAD and OPTIONS — are more behind-the-scenes, usually used for checking if a resource exists or for CORS preflight checks.

The Problem With Testing APIs

Here's something nobody talks about enough: testing APIs is just hard enough to be annoying.

It's not hard like writing a compiler or implementing a sorting algorithm. It's hard in a friction-filled, setup-heavy, "why am I spending 20 minutes on this" kind of way.

If you're a backend developer, you probably have curl muscle memory by now. But curl is unforgiving — one misplaced quote or escaped character and your beautifully crafted JSON body turns into garbage. And reading curl output when something goes wrong? Not exactly a pleasant experience.

Postman is the gold standard for a lot of teams, and for good reason — it's powerful. But powerful also means complex. Collections, environments, workspaces, team sync — it's a lot when you just want to fire off a quick request to see if an endpoint returns what it's supposed to. There's also the matter of it being a desktop app you need to install, update, and sometimes log into.

The other issue that catches developers off-guard — especially those newer to frontend work — is CORS.

CORS (Cross-Origin Resource Sharing) is a browser security feature that blocks your JavaScript from calling APIs on different domains unless the API explicitly says "yes, this domain can talk to me." It exists for genuinely good reasons (preventing malicious websites from making requests on your behalf), but it's also the source of an enormous amount of confusion and pain.

You'll write what looks like perfect code. You'll test it. You'll get a wall of red text in your browser console that says something like Access to fetch at 'https://api.example.com' from origin 'http://localhost:3000' has been blocked by CORS policy. And you'll wonder if you've done something horribly wrong.

You haven't. The API just doesn't allow browser-based requests from your origin. It'll work fine server-to-server — which is exactly why a server-side testing tool is so much more useful than a browser-based one.

Meet the Tool That Actually Fixes This

There's a free online REST API tester over at sadiqbd.com — specifically the REST API Checker — and honestly, it's become one of those tools I didn't know I needed until I started using it.

The concept is simple: you paste in your API URL, choose your method, add any headers or a request body, and hit Send. Within seconds you get back the full response — status code, response headers, response body (pretty-printed if it's JSON), and the time it took.

What makes it different from just opening your browser's Network tab is the server-side proxying. When you use this tool, the request doesn't come from your browser — it comes from their server. That completely bypasses CORS. It doesn't matter if the API has restrictive CORS headers or none at all. You'll get the real response, every time.

Let me walk through what it actually supports:

HTTP Methods: GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. Every method you'll realistically need.

Custom Headers: Add as many as you need. Authorization tokens, Content-Type overrides, custom API keys — any header the API expects, you can set it. The Authorization header field especially comes in handy when you're debugging authentication: Bearer your-token-here goes in just like you'd set it in code.

Request Body Formats: Three options — JSON (which auto-sets Content-Type: application/json), raw (for XML, plain text, or anything else), and multipart form-data (for file uploads). This is actually comprehensive enough to cover most real-world API testing scenarios.

Response Details: You get the status code, response time, body size, all response headers, and the formatted body. If the API returns JSON, it's automatically prettified so you can actually read it.

Real Scenarios Where This Saves Time

Scenario 1: You're integrating a new API and want to verify it works before writing any code.

This is the fastest use case. Copy the example request from the documentation, paste it in, run it. If it returns what the docs say it should, you know the API is working and your credentials are valid. Now you can write code with confidence.

Scenario 2: Something's broken in production and you need to isolate whether it's your code or the API.

Hit the API directly from the tester with the same payload your code sends. If it works there but not in your app, the bug is in your code. If it fails there too, the API is the problem. Five seconds of testing that would have taken you 20 minutes to debug otherwise.

Scenario 3: You're getting a 400 Bad Request and have no idea why.

This is where the response body matters. Most well-designed APIs return a JSON error object explaining what went wrong — missing field, wrong data type, invalid value. The pretty-printed response makes this readable immediately. Common culprits: missing required fields, wrong data types, or subtly malformed JSON (a trailing comma that's valid in JavaScript but not in strict JSON parsers).

Scenario 4: You're testing a webhook.

Webhooks are notoriously painful to debug. With this tool, you can replay a webhook payload to your endpoint and see exactly what it returns — useful for reproducing intermittent failures or testing your error handling.

Scenario 5: Comparing staging vs. production.

Swap the URL, keep everything else the same. If staging returns something different from production, you've found your environment drift. This kind of quick comparison is surprisingly hard to do cleanly with other tools.

A Few Things Worth Knowing

On API key safety: The tool doesn't store your request bodies, headers, or responses. That said, for genuinely sensitive production credentials — the ones that control real money or user data — it's wise to use scoped test keys or short-lived tokens. Not because this tool is untrustworthy, but because that's just good security hygiene regardless of what tool you're using.

On private/internal APIs: Since requests are made server-side, they need to reach a publicly accessible URL. Private IPs and loopback addresses (localhost, 192.168.x.x, etc.) are blocked for security reasons. For internal APIs, you'd need a tunneling tool like ngrok to expose them temporarily.

On file uploads: The multipart form-data option supports file attachments up to 5 MB each. That covers most practical file upload API testing scenarios — image upload endpoints, document imports, that kind of thing.

Beyond REST API Testing

While you're on sadiqbd.com, it's worth knowing the site is actually a full toolkit for developers and beyond. The developer section alone has a JSON Formatter (genuinely one of the most-used tools when working with APIs), a JWT Decoder (paste in any JWT and instantly see the header, payload, and expiry), a Regex Tester, Hash Generator, Base64 Encoder/Decoder, and more.

There are also internet tools for DNS lookups, SSL checking, HTTP header inspection, and port scanning — the kind of things you end up Googling every few weeks and wishing were in one place.

It's the sort of site that earns a browser bookmark pretty quickly.

The Bigger Picture

Here's what I actually think about when I look at a tool like this: the best developer tools are the ones that collapse friction.

The gap between "I want to test this API" and "I have my test result in front of me" should be as small as possible. Every minute spent setting up a client, remembering a password, updating software, or wrestling with a curl command is a minute not spent on the actual problem you're trying to solve.

The REST API Checker on sadiqbd.com doesn't do everything Postman does. It doesn't have saved collections or team collaboration or automated test suites. But it does the thing you need most of the time — send a request, see the response — with literally zero friction. Open a tab, paste a URL, click Send.

That's it.

For the quick tests, the late-night debugging sessions, the "let me just verify this works before I write the integration" moments — it's hard to beat.

Wrapping Up

REST APIs are everywhere. Understanding them — even at a surface level — makes you dramatically more effective as a developer, whether you're building backends, working on frontend integrations, or just trying to make sense of why something isn't working.

And having a fast, reliable, no-fuss way to test them? That's not a luxury. It's just practical.

Bookmark sadiqbd.com/developer/rest-api-checker. You'll use it more than you expect.

Found this useful? The full suite of developer tools — JSON formatter, JWT decoder, regex tester, and more — lives at sadiqbd.com.

Learn the basics about how REST APIs work

Sun, 23 Feb 2025 10:35:58 +0000

The Basics of RESTful APIs: A Beginner's Guide to Modern Web Communication

APIs (Application Programming Interfaces) are like bridges that allow different software applications to communicate. Think of APIs as middlemen who carry requests and responses from one system to another.

APIs make it possible for backend systems to communicate with frontend applications. For example, when you use a social media app, the app (or more specifically, the frontend) fetches information from the backend API to show you what you see on the screen (posts, comments, etc). APIs are very important to modern software, as they power almost everything from websites to mobile and enterprise applications.

Although there are different types of APIs, RESTful (or REST) APIs are the most popular and widely used. In this article, you will learn about REST APIs and why they are useful.

Understanding REST APIs

A REST API is an API that follows the principles of the REST architectural pattern for designing networked applications.

REST is the short form for REpresentational State Transfer. It is a set of guidelines or principles that determines how to build an API. Although REST has its own policies, it is not a standard or rigid protocol because every developer can implement REST in their own way.

REST APIs usually revolve around the concept of resources. Resources can be in different formats such as text, image, or video. You can interact with resources (read, update, delete, etc.) through each resource's dedicated endpoints or URLs.

Core Principles of REST APIs

Before an API qualifies as a REST API, some (or all) of these principles must be taken into account:

Statelessness: A REST API has to be stateless. This means that all the requests sent from a client application (think frontend, for ease) must contain all the information required to process that request.
A REST API will not retain any knowledge of previous requests or client sessions even if they are from the same client—it uses the data provided in the current request to respond.. Each request sent to a REST API must be independent of any other request.
Client-Server Architecture: A client-server architecture is a model where tasks are divided between two main components: clients and servers. Typically, a client sends a request to a server and the server sends back a response.
This model makes it possible for both the client and server to scale properly and independently; for example, you can change the entire user interface (client) without affecting the server or scale up the server without disrupting the client. A REST API must have a client-server architecture.
Cacheability: The data or response provided by a REST API should be cacheable by the client or intermediaries. This simply means the client can store the information sent by the server and use it later instead of making a new request.
Layered System: A REST API allows intermediaries, such as load balancers and proxies, to be inserted between the client and server without affecting the interaction. This makes the system more secure and scalable by distributing the load or filtering malicious requests.
Uniform Interface: This feature requires all REST APIs to have a standardized way of doing things. REST APIs must use the common HTTP methods to grant access to a resource and also use a standard format such as JSON or XML to present resources.
Things like naming conventions of endpoints and responses must be consistent and easy to understand.

HTTP Methods in REST APIs

An HTTP method or HTTP verb is a request method that tells the server the kind of action a client wants to perform on a resource. Every request sent to a REST API must contain an HTTP method.

REST APIs regularly use the following methods:

GET: The GET method tells the server to retrieve or get a specific resource. For example, on a blog website, you can use the GET method to view a list of articles or a single article.
POST: The POST method informs the server that the client wants to create a new resource. In modern applications, this can be anything from registering a new user to creating a post on social media. This new resource is stored on the server and can be viewed/retrieved with a GET method/request.
PUT/PATCH: Both PUT and PATCH methods mean the client wants to update a resource on the server. The PUT method allows the client to update the entire resource while the PATCH method allows the client to update small parts of the resource as it pleases. For example, updating a user profile or editing a blog post will use one of these methods.
DELETE: The DELETE method simply means the client wants to remove a resource from the server.

JSON as the Standard Format for REST APIs

JSON stands for JavaScript Object Notation and despite its name, it is language agnostic. This means JSON can be utilized in multiple programming languages without any issues. JSON is widely preferred over XML and other formats for REST APIs, because of its lightweight structure and ease of use.

Compared to XML, JSON typically results in smaller file sizes, which can lead to faster parsing and transmission. Additionally, JSON’s syntax is simple and easy to read, making it a more user-friendly option for developers.

Here is an example of a JSON object representing a person’s information:

{
  "firstName": "John",
  "lastName": "Doe",
  "age": 30,
  "address": {
    "street": "123 Main St",
    "city": "Anytown",
    "state": "CA",
    "postalCode": "12345"
  },
  "phoneNumbers": [
    {
      "type": "home",
      "number": "123-555-5555"
    },
    {
      "type": "work",
      "number": "123-555-5556"
    }
  ]
}

In the example above, you can observe the following:

The JSON object contains keys such as firstName, lastName, age, address, and phoneNumbers.
The value of address is another object (nested JSON object).
The value of phoneNumbers is an array of objects.

REST API Endpoints

In API development, endpoints are the URLs through which clients can interact with resources on a server.

Endpoints ensure the client and server are properly connected and handle the transfer of data between them.

A good API should always have clean, intuitive, and consistent endpoints that make it easy for developers to use and understand. REST API Endpoints usually follow a predictable and hierarchical structure to represent resources and their relationships. Here are some examples for an e-commerce application:

api/products/all - to retrieve a list of all the products in the application using a GET method.
api/products/:id - to retrieve a single product (GET method) using its unique ID.
api/products/create - to create a new product in the application using a POST method.
api/products/:id/update - to update an existing product using its unique ID with a PUT or PATCH method.

Conclusion

This article has explained the basic concepts of RESTful APIs and how they are very useful and easy for developers to implement. Although there are more advanced concepts, understanding the basics of REST APIs will give you an edge when you start creating or consuming APIs for your application.

If you enjoyed this article, like share and comment!