DEV Community: Dhairya Bhargava

How to Test Your First REST API with Postman: A Practical Walkthrough

Dhairya Bhargava — Wed, 30 Sep 2026 19:06:25 +0000

Every modern web application relies on Application Programming Interfaces (APIs) to exchange data between user interfaces and backend servers. Before writing code to consume an endpoint, verifying how that API responds is essential for preventing unexpected bugs and runtime errors.

Postman is the industry standard for manual API development and testing. It allows developers to construct HTTP requests, configure payloads, inspect response bodies, and verify status codes without writing client-side fetch logic.

This guide walks through sending an HTTP GET request, interpreting response codes, and validating JSON data using a live public endpoint.

Prerequisites

To follow along, you only need:

A modern web browser
A free Postman account (accessible at postman.com)

Understanding the Target Endpoint

We will test an endpoint provided by JSONPlaceholder, a free REST API designed for development and prototyping. We will query an individual post:

HTTP Method: GET
Target URL: https://jsonplaceholder.typicode.com/posts/1

A GET request retrieves data from the specified server without modifying any server-side state.

Step 1: Construct the GET Request

In your Postman workspace, click the + icon or open a request tab.
Ensure the HTTP method dropdown is set to GET.
In the request URL bar, enter:

[https://jsonplaceholder.typicode.com/posts/1]

Step 2: Send the Request and Inspect the Output

Click the blue Send button on the right side of the address bar.

Postman executes the network call and populates the response pane directly below the workbench:

Key Response Metrics:

Status Code (200 OK): Located on the right side of the response bar. A 200 series code indicates the server successfully received, understood, and fulfilled the request.

Latency: Displays the round-trip time in milliseconds (e.g., 37 ms), indicating network speed and server response time.

Payload Size: Shows the total transfer weight (e.g., 1.31 KB).

Step 3: Parse the Returned JSON Payload

Under the Body tab, ensure the display format is set to JSON and Pretty. The server returns a structured JSON object representing the requested resource:

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}

The payload contains key-value pairs (userId, id, title, body) ready to be mapped to frontend application state.

Essential HTTP Status Codes

When testing APIs, status codes quickly identify whether an issue lies with your request or the server:

200 OK: The request succeeded and returned the requested payload.

201 Created: A resource was successfully generated on the server (common for POST requests).

400 Bad Request: The request was malformed, had missing parameters, or contained invalid syntax.

401 Unauthorized: Missing or invalid authentication credentials (API key or bearer token).

404 Not Found: The requested endpoint path or specific resource ID does not exist.

500 Internal Server Error: An unhandled error occurred within the remote server logic.

Conclusion

In under five minutes, you tested a live REST endpoint, validated server availability via standard HTTP response codes, and verified payload formatting without writing single lines of application code. Postman isolates API testing from your frontend UI, giving you an immediate sanity check whenever backend behavior behaves unexpectedly.

Supabase vs. Firebase: Why Relational Databases Are Dominating Modern App Architecture

Dhairya Bhargava — Wed, 30 Sep 2026 18:46:28 +0000

For nearly a decade, Google’s Firebase was the default backend-as-a-service (BaaS) for startups, indie hackers, and mobile developers. Its promise was seductive: spin up an app without writing a single line of backend infrastructure code, sync JSON documents in real time, and scale horizontally on Google’s infrastructure.

However, as production applications mature, developers frequently encounter the structural bottlenecks of document-based NoSQL storage. Supabase emerged not merely as an "open-source Firebase alternative," but as an architectural course correction restoring relational integrity and SQL power to rapid application development.

Here is an architectural breakdown of why developers are moving toward relational backends, how Supabase and Firebase diverge under the hood, and how to select the right platform for your stack.

1. Data Modeling: Structured Tables vs. Document Collections

The fundamental architectural difference between both platforms lies in data organization:

Firebase (Cloud Firestore): A document-oriented NoSQL database. Data lives in loose JSON like structures organized into collections and subcollections. Documents within the same collection do not need to share the same schema.
Supabase: An automated layer on top of a dedicated PostgreSQL relational database. Data lives in strictly typed tables with explicit column constraints, foreign keys, and referential integrity.

The Reality in Production

NoSQL offers incredible velocity during early prototyping when your schema changes daily. However, as business logic grows, applications inevitably require relational data: users have multiple orders, orders reference inventory items, and inventory belongs to organizations.

In Firebase, managing relationships requires denormalization—duplicating data across multiple documents. If a user updates their profile picture or username, your application code must find and update dozens of separate documents. If any update fails mid flight, your database falls into an inconsistent state.

2. Querying Capabilities: SQL Joins vs. Client-Side Stitching

Querying data across multiple entities exposes the steepest difference between the two systems:

In Firebase:

Cloud Firestore does not support relational JOIN operations. If an admin dashboard needs to display a list of orders alongside customer profile details, the client application must:

Fetch the orders collection.
Extract the user_id from each order.
Make individual queries back to the users collection to retrieve user profiles.
Manually stitch the responses together in JavaScript.

This "N+1 query problem" inflates network overhead, drains mobile battery life, and multiplies database read costs.

In Supabase:

Because Supabase exposes native PostgreSQL over autogenerated REST and GraphQL endpoints, relational queries happen in a single trip. Using standard SQL or the Supabase JavaScript client, you query relational data through a simple nested query:

const { data, error } = await supabase
  .from('orders')
  .select(`
    id,
    total_amount,
    users (
      id,
      email,
      full_name
    )
  `);

3. Access Control: Security Rules vs. Row Level Security (RLS)

Both platforms prevent client side operations from unauthorized data access, but enforce security at completely different layers:

Firebase Security Rules: Relies on a proprietary, declarative domain specific language (DSL). While capable, debugging complex access rules across nested subcollections requires specialized testing harnesses and can become brittle as schemas evolve.

Supabase Row Level Security (RLS): Operates natively within PostgreSQL. Access policies are standard SQL expressions attached directly to tables.

With Supabase RLS, authorization rules look like standard database logic:

SQL

create policy "Users can only view their own tasks"
on tasks for select
using (auth.uid() = user_id);

Because security logic resides inside Postgres rather than an external gateway, the same rules apply whether requests arrive via the Supabase web SDK, an Edge Function, or a direct database connection string.

4. Pricing Mechanics: Capacity-Based vs. Operation-Based

Cost predictability often dictates backend migration decisions at scale:

Primary Billing Metric: Firebase charges per operation (reads, writes, and deletes), whereas Supabase bills based on provisioned compute capacity and storage tiers.
Pricing Predictability: Firebase costs can surge unpredictably with viral traffic spikes or unoptimized front end render loops. Supabase operates on fixed monthly tiers with predictable limits.
Portability & Lock-in: Firebase ties your architecture to proprietary Google Cloud services. Supabase is built entirely on standard, portable open-source PostgreSQL.
Deployment Flexibility: Firebase is strictly cloud hosted; Supabase can be deployed to the cloud or self-hosted on your own infrastructure via Docker.
Realtime Engine: Firebase uses native document synchronization, while Supabase uses PostgreSQL logical replication.

Firebase charges per document read and write. An unintentional infinite loop in front end React hooks or a sudden viral spike can trigger thousands of dollars in surprise operational charges overnight.

Supabase bills on provisioned compute capacity and storage tiers. A compute instance costs a flat monthly rate regardless of whether a query retrieves 10 records or 100,000 records.

Architectural Verdict: When to Choose Which

Choose Firebase if:

You are building a mobile first application where offline caching and seamless local to remote conflict resolution are core requirements.

Your engineering stack already integrates deeply with the Google Cloud ecosystem (BigQuery, Firebase Cloud Messaging, Vertex AI).

Your data is naturally non relational (e.g., event logs, isolated chat logs, simple real-time canvas states).

Choose Supabase if:

Your product handles structured, interconnected business logic (SaaS tools, marketplaces, CRM systems, e-commerce).

You want transparent data ownership without vendor lock in; you can dump your Postgres database and migrate to AWS RDS or a self hosted server anytime.

Your team requires advanced analytical querying, aggregation, full text search, or vector embeddings (pgvector) without deploying external search clusters.

The developer community's shift toward Supabase is not just about avoiding proprietary ecosystems it reflects a broader recognition that foundational relational modeling remains the most resilient architecture for long term product growth.

How to Set Up a Free Cloud Database and Add Your First Table with Supabase

Dhairya Bhargava — Wed, 30 Sep 2026 18:21:25 +0000

Setting up a backend database traditionally meant provisioning virtual machines, managing port forwarding, and writing manual SQL schemas before writing a single line of application logic. Supabase removes this friction by delivering a managed, cloud-hosted PostgreSQL database in minutes, manageable entirely through an intuitive browser interface.

This guide walks through creating a Supabase project, building a structured data table visually, inserting records, and accessing client connection configurations

Prerequisites

To complete this walkthrough, you only need:

A modern web browser
A free GitHub account or personal email address

Step 1: Create a New Supabase Project

Navigate to supabase.com and select Start your project.
Sign in with GitHub or your email credentials.
Select New project from your organization dashboard.
Set the Project name to Task Manager DB.
Click Generate a password to generate a secure database password, and store it safely.
Choose the Region closest to your target audience (e.g., Asia-Pacific).
Confirm the project is on the Free tier and click Create new project.

Supabase will provision your isolated PostgreSQL database instance in the background.

Step 2: Build a Table Using the Visual Editor

Once provisioning completes, you can construct relational tables without writing raw DDL statements:

Click the Table Editor icon (the grid icon) on the left sidebar.
Select Create a table (or + New table).
Set the Name to Tasks and add an optional description: A list of daily tasks to track.
Keep the default columns:
- id (int8, primary key)
- created_at (timestamptz, default: now())
Click Add column twice to append your application attributes:
- Column 3: Name: title | Type: text | Default: empty
- Column 4: Name: is_completed | Type: bool | Default: false
Keep Enable Row Level Security (RLS) selected to safeguard public access policies.

Click Save in the bottom-right corner to commit the table schema.

Step 3: Insert Sample Records

With the schema live, populate sample rows directly through the dashboard interface:

Click Insert in the top action bar, then choose Insert row.
Leave id and created_at empty; the database populates both values automatically.
In the title field, type: Write my first technical article.
Leave is_completed set to false, then click Save.
Repeat the process to add a second record: Pitch my sample guide to clients.

Your data will instantly appear in the spreadsheet viewer, complete with primary keys and timestamps.

Step 4: Access Client Connection Snippets

Supabase automatically generates context-aware snippets and client configs based on your active schema:

Click the green Connect button in the top navigation bar.
Under the Framework tab, select your environment (such as Next.js with the App Router).
Copy the package install command:


npm install @supabase/supabase-js @supabase/ssr

Review the ready-to-use .env.local snippet containing your project URL and public publishable key

Conclusion

In under ten minutes, you have provisioned a cloud PostgreSQL instance, created a structured table with appropriate data types, populated records visually, and retrieved ready-to-use client initialization credentials. From here, you can query this data directly from any web or mobile front-end using the @supabase/supabase-js software development kit.