<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Api on ilham.dev</title><link>https://ilham.dev/tags/api/</link><description>Recent content in Api on ilham.dev</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sun, 27 Sep 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://ilham.dev/tags/api/index.xml" rel="self" type="application/rss+xml"/><item><title>How I build a Basic Auth header for testing</title><link>https://ilham.dev/posts/how-to-build-a-basic-auth-header-for-testing/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-build-a-basic-auth-header-for-testing/</guid><description>Basic Auth sends a username and password encoded with Base64 inside an Authorization header. It is not encryption by itself.
The Basic Auth Header tool helps with the mechanical part, but I still check the result before using it somewhere real.</description></item><item><title>How I build mock API responses that look real enough for frontend work</title><link>https://ilham.dev/posts/how-to-build-mock-api-responses-that-look-real-enough/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-build-mock-api-responses-that-look-real-enough/</guid><description>Mock responses help frontend and integration work move before the real backend endpoint is finished.
The API Mock Response Builder tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.</description></item><item><title>How I check a JWT when an API login looks broken</title><link>https://ilham.dev/posts/how-to-read-and-verify-jwt/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-read-and-verify-jwt/</guid><description>A JWT is one of those strings that looks scary the first time you see it. It often appears in a login response, browser storage, or an API request header:</description></item><item><title>How I compare two JSON responses without being distracted by formatting</title><link>https://ilham.dev/posts/how-to-compare-json-without-being-distracted-by-formatting/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-compare-json-without-being-distracted-by-formatting/</guid><description>A JSON diff should compare meaning, not indentation. Two JSON documents can look different as text but still contain the same data.
The JSON Diff tool is useful because it lets me check the result in a small, controlled place before I use it in a bigger workflow.</description></item><item><title>How I convert a curl command into code I can actually use</title><link>https://ilham.dev/posts/how-to-convert-curl-commands-into-code/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-convert-curl-commands-into-code/</guid><description>API documentation often gives examples as curl commands:
curl -X POST https://api.example.com/users \ -H &amp;#34;Authorization: Bearer TOKEN&amp;#34; \ -H &amp;#34;Content-Type: application/json&amp;#34; \ -d &amp;#39;{&amp;#34;name&amp;#34;:&amp;#34;Ana&amp;#34;}&amp;#39; That is useful for testing, but eventually I need the same request in application code.</description></item><item><title>How I create and check HMAC signatures for API requests</title><link>https://ilham.dev/posts/how-to-create-and-check-hmac-signatures/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-create-and-check-hmac-signatures/</guid><description>HMAC proves that a message was created by someone who knows the shared secret, and that the signed message has not changed.
The HMAC Generator tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.</description></item><item><title>How I debug CORS without guessing</title><link>https://ilham.dev/posts/how-to-debug-cors-without-guessing/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-debug-cors-without-guessing/</guid><description>CORS errors are frustrating because the browser often shows a scary message, but the real cause is usually a small missing header.
You may see something like this in the browser console:</description></item><item><title>How I format JSON before debugging it</title><link>https://ilham.dev/posts/how-to-format-json-before-debugging-it/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-format-json-before-debugging-it/</guid><description>JSON is easier to debug when it is valid and formatted. A formatter turns one long line into a structure humans can read.
The JSON Formatter tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.</description></item><item><title>How I look up HTTP status codes during debugging</title><link>https://ilham.dev/posts/how-to-look-up-http-status-codes-during-debugging/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-look-up-http-status-codes-during-debugging/</guid><description>HTTP status codes are short signals from a server. They tell me whether a request succeeded, redirected, failed on the client side, or failed on the server side.
The HTTP Status Codes tool helps me inspect the input and output without writing a one-off script first.</description></item><item><title>How I read a curl command before I run it</title><link>https://ilham.dev/posts/how-to-read-a-curl-command-before-running-it/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-read-a-curl-command-before-running-it/</guid><description>A curl command is an HTTP request written for the terminal. Before running one from documentation or chat, I want to know what it will send.
The curl Tester tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.</description></item><item><title>How I read an OpenAPI file before using an API</title><link>https://ilham.dev/posts/how-to-read-an-openapi-file-before-using-an-api/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-read-an-openapi-file-before-using-an-api/</guid><description>An OpenAPI file is machine-readable API documentation. It describes endpoints, inputs, outputs, and authentication expectations.
The OpenAPI Viewer tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.</description></item><item><title>How I read HTTP headers when an API or website behaves strangely</title><link>https://ilham.dev/posts/how-to-read-http-headers/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-read-http-headers/</guid><description>HTTP headers are small pieces of metadata sent with a request or response. They can explain things that are not visible in the page body.
When a website or API behaves strangely, I often look at the headers first.</description></item><item><title>How I test an HTTP request before writing the code around it</title><link>https://ilham.dev/posts/how-to-test-an-http-request-before-writing-code/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-test-an-http-request-before-writing-code/</guid><description>Before I put an API call into code, I like to prove the request works by itself: URL, method, headers, body, and response.
The HTTP Request Tester tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.</description></item><item><title>How I test gRPC when normal HTTP tools are not enough</title><link>https://ilham.dev/posts/how-to-test-grpc-when-http-tools-are-not-enough/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-test-grpc-when-http-tools-are-not-enough/</guid><description>gRPC APIs do not look like normal REST endpoints. Instead of paths like /users, you call service methods with typed messages.
The gRPC Tester tool gives me a safe place to test the idea before I put it into a script, server, or production workflow.</description></item><item><title>How I test webhooks before trusting them</title><link>https://ilham.dev/posts/how-to-test-webhooks-safely/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-test-webhooks-safely/</guid><description>A webhook is a simple idea: one system sends an HTTP request to another system when something happens.
For example:
Stripe sends a webhook when a payment succeeds; GitHub sends a webhook when someone pushes code; Shopify sends a webhook when an order is created.</description></item><item><title>How I understand SNAP BI asymmetric signatures step by step</title><link>https://ilham.dev/posts/how-to-understand-snap-bi-asymmetric-signature/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-understand-snap-bi-asymmetric-signature/</guid><description>SNAP BI signatures can feel confusing because they combine several ideas at once:
HTTP method; URL path; request body hash; timestamp; RSA private and public keys; a signature header. When all of those appear together, it is easy to get lost.</description></item><item><title>How I use a JSON viewer when an API response is too large to read</title><link>https://ilham.dev/posts/how-to-use-json-viewer-for-large-api-responses/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-use-json-viewer-for-large-api-responses/</guid><description>A JSON viewer is for exploring structure. It helps me see objects, arrays, nested fields, and repeated records without reading one long block of text.
The JSON Viewer tool is useful because it lets me check the result in a small, controlled place before I use it in a bigger workflow.</description></item><item><title>How I use JSONPath when a JSON response is too big to read</title><link>https://ilham.dev/posts/how-to-use-jsonpath-to-find-data/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-use-jsonpath-to-find-data/</guid><description>Small JSON is easy to read. Large JSON is different. A real API response can contain nested objects, arrays, metadata, and fields you do not care about.
JSONPath helps ask focused questions like:</description></item><item><title>How I validate JSON with a schema before blaming the API</title><link>https://ilham.dev/posts/how-to-validate-json-with-a-schema/</link><pubDate>Sun, 27 Sep 2026 00:00:00 +0700</pubDate><guid>https://ilham.dev/posts/how-to-validate-json-with-a-schema/</guid><description>When an API receives JSON, it usually expects a certain shape. If one field is missing or one value has the wrong type, the request may fail.
A JSON Schema describes that expected shape.</description></item></channel></rss>