DEV Community: paohaijiao

From Copy-Pasting curl Commands to Building My Own Java Parser (jquick-curl)

paohaijiao — Thu, 17 Sep 2026 23:08:30 +0000

How a QA handoff turned into a weekend rabbit hole and eventually an open-source library

Tags: java, opensource, http, curl, backend

The Slack message that started it all

It's 4:47 PM on a Thursday. QA drops this in the channel:

curl -X POST https://api.internal.example.com/orders \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIs...' \
  -H 'X-Trace-Id: 8f14e45f' \
  -d '{"sku":"A-1001","count":2,"warehouse":"SH-03"}'

"Can you check why this fails in staging but works for me locally?"

Cool. Easy. I just need to reproduce this in our Java service. So I open the controller, and I start... translating.

-X POST → okay, HttpMethod.POST. -H lines → I build a HttpHeaders object, add each one by hand, careful not to typo Authorization. -d → I need a MultiValueMap or just serialize the JSON string directly into the body, depends on which client we're using this week. Then I remember we're on RestTemplate in this module but OkHttp in that other module, so I have to remember which boilerplate applies here.

Ten minutes later I've got a Java snippet that should be equivalent to the curl command. I run it. It fails differently than staging did. I stare at both side by side for a solid two minutes before I notice I dropped a header. Of course I did — I was hand-transcribing eight lines of shell syntax into a completely different language's HTTP client API, header by header, like a monk copying a manuscript.

And this wasn't a one-off. This was Tuesday. This was every integration week. Front-end hands me curl from their network tab, API docs ship curl examples, QA pastes curl into bug reports — curl is the lingua franca everyone actually uses to describe an HTTP call. Nobody writes a bug report in OkHttpClient Java syntax. They all just hit copy on the "Copy as cURL" button in devtools.

So I was translating the same universal language into Java, by hand, multiple times a day. And translating things by hand, repeatedly, is exactly the kind of problem that eventually makes you angry enough to fix it.

Why I didn't just reach for an existing tool

Before writing a single line, I did what everyone does — I went looking for something that already solved this.

Option 1: Just shell out to the real curl binary. Java's ProcessBuilder can absolutely call the system curl command and read stdout. I actually prototyped this first. It "worked," but I hated it almost immediately. It meant every machine running my service — dev laptops, CI runners, Docker images, production hosts — now had a hard dependency on a specific curl binary being installed and on PATH, with a specific version, potentially with different flag support across platforms. On Windows it was a mess. In a minimal Alpine-based Docker image, curl isn't even there by default. I didn't want my Java library to depend on the presence of a totally separate program written in C. It's not portable, it's fragile, and honestly it felt wrong to spawn an OS process just to make an HTTP call from inside the JVM.

Option 2: Use one of those "curl to code" online converters. These are fine for a single one-off translation, but they don't solve my actual problem — I don't want a Java code generator I paste output from once. I want the curl string itself to be the source of truth, permanently, so that when QA sends me an updated curl next sprint, I don't regenerate and re-paste new boilerplate again. I want to keep the curl command in my codebase, unmodified, and have it stay useful.

Option 3: Just write the RestTemplate/OkHttp code properly, like an adult. Yeah, obviously that's what I'd been doing. But it's exactly the boilerplate-per-endpoint problem — headers, method, body serialization, timeouts — repeated for every single API call in the codebase. None of that boilerplate teaches anyone anything; it's just friction between "I have a working curl command" and "I have a working Java call."

What I actually wanted was something that didn't exist: a way to parse curl syntax natively inside the JVM, with no external process, and turn it straight into an executable HTTP call. Not a code generator. Not a wrapper around a shell binary. An actual parser.

Designing jquick-curl

The core idea, once I let myself think about it properly, was almost stupidly simple: the curl command a person hands me should just work, unmodified, as the request definition. I shouldn't have to rewrite it into anything. I should be able to paste it straight from Chrome's "Copy as cURL," slap it on a Java interface method, and call that method.

That meant I needed a real grammar for curl syntax, not a pile of regex and String.split() hacks (I tried that first, for about a day, before giving up — curl's quoting rules, escaped characters inside -d payloads, and mixed short/long flags make naive string splitting fall apart fast). So I reached for ANTLR4 to define a proper grammar for the subset of curl I cared about: methods, headers, cookies, body flags, form/multipart uploads, auth, proxy settings, redirects. ANTLR runs entirely inside the JVM — no external process, no shelling out, no platform dependency. It parses the curl string into a syntax tree I can walk and turn into a structured request object. That single decision is what let me kill the "depend on a real curl binary" idea for good: jquick-curl runs identically on Windows, Linux, and Mac, and doesn't care whether curl is even installed on the machine.

Once I had a parsed request, I needed something to actually execute it, and there was no reason to reinvent that part — OkHttp underneath handles the real transport: connection pooling, timeouts, retries, redirects, interceptors. jquick-curl's job is purely to bridge "curl syntax" to "OkHttp request," not to replace a mature HTTP engine.

Then came the part that made it feel like an actual tool instead of a toy parser: how do you attach a curl string to your codebase in a way that fits how Java developers actually work? I ended up supporting two styles:

An annotation, @JCurlCommand, that you drop directly on an interface method — you paste the curl string as-is, and a dynamic proxy (JCurlInvoker.createProxy(...)) turns the interface into a real client at runtime.
An XML definition file (apis.xml), for teams who'd rather centralize every API's curl template in one place instead of scattering them across annotations — handy when non-Java people (QA, API owners) are the ones maintaining the request definitions.

From there I kept adding the things that came up naturally once I started actually using it for real work: ${name} / #{name} placeholder substitution so a curl template isn't hard-coded per environment, <if test="..."> conditional rendering in the XML flavor for headers that only apply sometimes, cookie jar support (-b @file, -c file) because our session-based APIs needed it, multipart upload and file download via -F and -o, global interceptors for things like injecting a bearer token, and retry/timeout/connection-pool config through one JQuickCurlConfig singleton instead of per-call setup.

None of that was planned up front, honestly — it grew out of "oh, I need this for the thing I'm debugging right now" over a few weekends.

What it actually looks like

Add the dependency:

<dependency>
    <groupId>io.github.paohaijiao</groupId>
    <artifactId>jquick-curl</artifactId>
    <version>2.5.0</version>
</dependency>

Take that curl command from earlier — the one from the Slack message — and just... put it on an interface:

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;
import com.github.paohaijiao.executor.JCurlInvoker;

public interface OrderApi {

    @JCurlCommand("curl -X POST https://api.internal.example.com/orders " +
            "-H 'Content-Type: application/json' " +
            "-H 'Authorization: Bearer ${token}' " +
            "-H 'X-Trace-Id: ${traceId}' " +
            "-d '{\"sku\":\"A-1001\",\"count\":2,\"warehouse\":\"SH-03\"}'")
    String createOrder(JQuickCurlReq request);
}

class Demo {
    public static void main(String[] args) throws Exception {
        OrderApi api = JCurlInvoker.createProxy(OrderApi.class);

        JQuickCurlReq req = new JQuickCurlReq();
        req.put("token", System.getenv("API_TOKEN"));
        req.put("traceId", "8f14e45f");

        String body = api.createOrder(req);
        System.out.println(body);
    }
}

No HttpHeaders. No manually building a request body. No deciding which client's boilerplate applies this week. The curl string is the request definition — I literally paste what QA sent me, swap the hardcoded secrets for ${token} placeholders, and I have a working method.

Where I'd be lying if I said this solves everything

I want to be straight about this, because I've seen enough "this library changes everything" posts to be allergic to writing one myself.

jquick-curl is not trying to replace RestTemplate or OkHttp for general-purpose HTTP client code in your application. If you're building a service that needs fine-grained, programmatic control over request construction — conditional logic that's too complex for a template string, streaming request bodies, custom RequestBody implementations, deep integration with Spring's ecosystem (WebClient, reactive pipelines, circuit breakers via Resilience4j, etc.) — you're still better off writing that in actual OkHttp or RestTemplate code. jquick-curl is a thin layer that turns curl syntax into an OkHttp call; it's not trying to out-feature a mature HTTP client.

Where it genuinely earns its place, in my experience, is a fairly specific niche: reproducing and calling APIs that are described to you as curl commands — QA bug reports, third-party API docs that only ship curl examples, internal service-to-service calls you're debugging by pasting from a browser's network tab, or integration test suites where "does this curl still work" is literally the assertion you want to make. It's also handy for quick internal tooling where you want request definitions to be editable by non-Java teammates via the XML config, without touching Java code.

The honest limitations right now: the curl grammar covers a solid, tested subset of options (method, headers, cookies, data variants, form/multipart, basic auth, redirects, proxy, -k/-v/-s, HTTP/2) — but curl has a lot of flags, and I haven't chased every obscure one. If you hit something unsupported, the parser will tell you, not silently misbehave, but it's still a smaller surface than the real curl binary. Error messages from the ANTLR parser can also be more cryptic than I'd like when someone pastes malformed shell quoting — that's on my list to improve. And it's still a fairly young project, so I wouldn't bet a critical production path on it without your own test coverage around it yet.

Try it, break it, tell me

Repo's here: github.com/paohaijiao/jquick-curl — Apache 2.0, PRs welcome, and CONTRIBUTING.md has the setup if you want to poke at the ANTLR grammar yourself.

Two things I'm genuinely curious about from other backend folks:

Do you hit the same "curl handed to me, translate it by hand" friction, or does your team already have some internal convention that avoids this? I'd love to know if this is a me-problem or an us-problem.
If you have rolled your own curl-parsing tool before (I have to believe someone has), what broke first — quoting edge cases, multipart handling, something else?

Drop it in the comments — I read all of them, and half the feature list above exists because someone told me what they needed.

Want this saved as a downloadable Markdown file for dev.to, or is copy-pasting from here fine?

Interceptors That Actually Help: Request Logging and Automatic Bearer-Token Injection

paohaijiao — Wed, 16 Sep 2026 22:52:12 +0000

Interceptors That Actually Help: Request Logging and Automatic Bearer-Token Injection

Cross-cutting HTTP concerns — logging, authentication headers, request IDs, metrics — should never be hand-edited into every request. JQuickCurl rides on OkHttp's mature interceptor pipeline, and because interceptors are wired into the global configuration, a single registration upgrades every curl command in your application.

In this post:

What an interceptor sees and can do.
The built-in JLoggingInterceptor.
Writing a request/response logging interceptor.
Auto-injecting a Bearer token from your secret store.

The Interceptor Model in One Paragraph

An OkHttp Interceptor wraps a call: it receives the outgoing Request, may modify it, calls chain.proceed(...), and then sees the returned Response. Registering interceptors happens on the global config, so both annotation-mode and XML-mode commands pass through them.

Interceptor myInterceptor = chain -> {
    Request request = chain.request();      // outgoing
    Response response = chain.proceed(request); // perform + get response
    return response;
};

JQuickCurlConfig.getInstance().addInterceptor(myInterceptor);

addNetworkInterceptor(...) registers at the network layer (after redirects/retries) when you need to observe the real wire traffic.

Built-In Logging: `JLoggingInterceptor`

Out of the box, the config already registers a JLoggingInterceptor at level ALL — it measures each call and reports the elapsed time (and failures) through its console logger. If you want a quieter default, the same interceptor can be constructed with an explicit level:

public enum JCurlLevelLog {
    NONE, BASIC, HEADERS, ALL
}

import com.github.paohaijiao.enums.JCurlLevelLog;
import com.github.paohaijiao.interceptor.JLoggingInterceptor;
import com.github.paohaijiao.config.JQuickCurlConfig;

JQuickCurlConfig.getInstance()
        .addInterceptor(new JLoggingInterceptor(JCurlLevelLog.BASIC));

Expect output in the spirit of: the request cost : 132 ms. Choose the noisiest level in development, BASIC in staging, and keep an eye on token redaction (see below).

Writing a Purpose-Built Logging Interceptor

Build one that logs method, URL, status, and duration — and be deliberate about what you don't log (authorization headers!).

import okhttp3.Interceptor;
import okhttp3.Request;
import okhttp3.Response;
import okhttp3.ResponseBody;

public class CallLogInterceptor implements Interceptor {

    private static final org.slf4j.Logger log =
            org.slf4j.LoggerFactory.getLogger(CallLogInterceptor.class);

    @Override
    public Response intercept(Chain chain) throws java.io.IOException {
        Request request = chain.request();
        long start = System.nanoTime();

        Response response = chain.proceed(request);

        long tookMs = java.util.concurrent.TimeUnit.NANOSECONDS.toMillis(
                System.nanoTime() - start);
        String bodyPreview = "";
        if (response.body() != null) {
            bodyPreview = safePreview(response.peekBody(256).string());
        }

        log.info("[http] {} {} -> {} in {} ms body={}",
                request.method(), request.url(), response.code(), tookMs, bodyPreview);
        return response;
    }

    private String safePreview(String s) {
        return s == null ? "" : s.replace('\n', ' ').substring(
                0, Math.min(120, s.length()));
    }
}

JQuickCurlConfig.getInstance().addInterceptor(new CallLogInterceptor());

Automatic Bearer-Token Injection

Tokens expire, rotate, and come from secret managers — they don't belong in @JCurlCommand strings. One interceptor can stamp every outgoing request with the current token:

import okhttp3.Interceptor;
import okhttp3.Request;
import okhttp3.Response;

public class BearerAuthInterceptor implements Interceptor {

    private final java.util.function.Supplier<String> tokenSupplier;

    public BearerAuthInterceptor(java.util.function.Supplier<String> tokenSupplier) {
        this.tokenSupplier = tokenSupplier;
    }

    @Override
    public Response intercept(Chain chain) throws java.io.IOException {
        String token = tokenSupplier.get();
        Request request = chain.request().newBuilder()
                .addHeader("Authorization", "Bearer " + token)
                .build();
        return chain.proceed(request);
    }
}

Because the token is fetched per request via a Supplier, rotating tokens are picked up automatically — no restart, no stale header. Wire it with your vault/environment source:

import com.github.paohaijiao.config.JQuickCurlConfig;

JQuickCurlConfig.getInstance().addInterceptor(
        new BearerAuthInterceptor(() -> System.getenv("API_TOKEN")));

Now a plain command stays clean:

@JCurlCommand("curl -X GET 'https://api.example.com/me'")
String me(JQuickCurlReq request);   // Authorization stamped by interceptor

The same trick works for API keys, X-Correlation-Id, tenant headers, and basic-auth pairs (Post 15).

Runnable Demo

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.config.JQuickCurlConfig;
import com.github.paohaijiao.domain.req.JQuickCurlReq;
import com.github.paohaijiao.executor.JCurlInvoker;

public interface InspectApi {
    // httpbin.org/headers echoes every header the server received
    @JCurlCommand("curl -X GET 'https://httpbin.org/headers'")
    String headers(JQuickCurlReq request);
}

class InterceptorDemo {
    public static void main(String[] args) {
        JQuickCurlConfig.getInstance().addInterceptor(chain -> {
            okhttp3.Request r = chain.request().newBuilder()
                    .addHeader("Authorization", "Bearer demo-token-123")
                    .build();
            return chain.proceed(r);
        });

        String echo = JCurlInvoker.createProxy(InspectApi.class)
                .headers(new JQuickCurlReq());
        System.out.println(echo);   // "Authorization": "Bearer demo-token-123"
    }
}

Ordering and Pitfalls

Interceptors run in registration order (application interceptors before network interceptors).
Headers you add in an interceptor are applied on top of whatever the curl string specified.
Never log or stash raw Authorization values — hash or redact in logs.
Keep interceptors fast; they run on the request thread.

Summary

Interceptors are the clean seam for concerns that cut across every HTTP call. JQuickCurl comes with timing-oriented logging out of the box and accepts any OkHttp interceptor through JQuickCurlConfig, so adding per-request Bearer tokens, correlation IDs, or metrics is a five-line change — while your curl commands stay declarative and secret-free.

Repository: dromara/jquick-curl. Post 13 shows per-method timeout overrides with @JTimeout when one stubborn endpoint needs different limits than the rest.

java #springboot #httpclient #opensource #java-library

Downloads Without Boilerplate: Saving HTTP Responses to Local Disk with `--output`

paohaijiao — Tue, 15 Sep 2026 23:01:23 +0000

Downloading a file in OkHttp means streaming ResponseBody, choosing a sink, and closing resources correctly. In JQuickCurl, a download is just another curl command: add --output './download/report.pdf' (or -o) and the executor writes the response bytes to that path for you. No InputStream juggling, no try-with-resources plumbing in your business code.

This post covers:

The --output one-liner that saves straight to disk.
Returning byte[] and saving in Java for full control.
Combined approaches and directory-handling notes.
A runnable demo against a real image endpoint.

Approach 1: Let the Command Write the File

The cleanest option. Add --output <path> to the curl command; the file appears at the path when the call returns.

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;

public interface DownloadApi {

    @JCurlCommand("curl -X GET 'https://httpbin.org/image/png' "
            + "--output './download/diagram.png'")
    byte[] downloadPng(JQuickCurlReq request);
}

import com.github.paohaijiao.executor.JCurlInvoker;

public class DownloadDemo {
    public static void main(String[] args) throws Exception {
        DownloadApi api = JCurlInvoker.createProxy(DownloadApi.class);
        byte[] bytes = api.downloadPng(new JQuickCurlReq());

        java.nio.file.Path file = java.nio.file.Paths.get("./download/diagram.png");
        System.out.println("Saved " + bytes.length + " bytes to "
                + file.toAbsolutePath());
        // -> Saved NNNN bytes to .../download/diagram.png
    }
}

Two things happen: the executor writes ./download/diagram.png, and (because the method still declares byte[]) you also receive the bytes — handy for checksumming or counting without an extra read. The directory must exist; JQuickCurl writes the file but does not create parent folders for you.

Approach 2: Return the Bytes and Save in Java

If the storage location is business logic (a database column, an S3 bucket, a temp dir chosen per tenant), skip --output and save the byte[] yourself:

public interface DownloadApi {

    @JCurlCommand("curl -X GET 'https://httpbin.org/bytes/4096'")
    byte[] downloadBytes(JQuickCurlReq request);
}

byte[] bytes = api.downloadBytes(new JQuickCurlReq());

java.nio.file.Files.write(
        java.nio.file.Paths.get("./download/random-4k.bin"), bytes);

Return types handled by the converter include byte[], and JResult for raw access. Choose by payload size:

Payload	Return type
Small / needs random access	`byte[]`
Medium, file target known in command	`--output` in command (any return)
Need metadata too	`JResult`

Directory Setup and Path Conventions

Pre-create the target directory (e.g., ./download) before the first call.
Prefer forward slashes — --output './download/report.xlsx' is portable.
On Windows, absolute paths like 'd://test//piett.xlsx' are the spelling used in the project's own XML samples; Java strings will treat \ as escapes, so / is the low-friction choice.
For versioned downloads, inject the file name via a variable:

@JCurlCommand("curl -X GET 'https://api.example.com/files/${fileId}' "
        + "-H 'Accept: application/octet-stream' "
        + "--output './download/${fileId}'")
byte[] downloadById(JQuickCurlReq request);

JQuickCurlReq req = new JQuickCurlReq();
req.put("fileId", "invoice-2026-03.pdf");
byte[] bytes = api.downloadById(req);
// file lands at ./download/invoice-2026-03.pdf

Complete Runnable Demo

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;
import com.github.paohaijiao.executor.JCurlInvoker;

public interface MediaApi {

    // Image with a header check to prove headers are respected
    @JCurlCommand("curl -X GET 'https://httpbin.org/image/jpeg' "
            + "-H 'Accept: image/jpeg' "
            + "--output './download/photo.jpg'")
    byte[] grabPhoto(JQuickCurlReq request);
}

class SaveToDiskDemo {
    public static void main(String[] args) throws Exception {
        java.nio.file.Files.createDirectories(java.nio.file.Paths.get("./download"));

        MediaApi api = JCurlInvoker.createProxy(MediaApi.class);
        byte[] bytes = api.grabPhoto(new JQuickCurlReq());

        System.out.println("Received " + bytes.length + " bytes");
        // Then verify the file on disk:
        long onDisk = java.nio.file.Files.size(
                java.nio.file.Paths.get("./download/photo.jpg"));
        System.out.println("On disk      : " + onDisk + " bytes");
    }
}

Summary

Downloads collapse into one declarative flag: --output './path' writes the response to disk, while return types byte[] keep the memory footprint in your control. Combined with ${...} variables for file names, JQuickCurl handles the whole download lifecycle with the syntax every engineer already knows.

Code and docs live at dromara/jquick-curl. Post 11 moves from per-request concerns to the process level: global tuning of connection pools, timeouts, retries, and redirects.

java #springboot #httpclient #opensource #java-library

Multipart Uploads Made Simple: Sending Files with curl's `-F` Flag in Java

paohaijiao — Mon, 14 Sep 2026 17:10:34 +0000

Every admin console ends up with a file upload — Excel imports, avatar pictures, PDF attachments. Implementing multipart requests by hand in OkHttp or RestTemplate means building MultipartBody pieces, computing Content-Type boundaries, and leaking HTTP plumbing into service code. In JQuickCurl you simply keep curl's -F file=@/path/to/file syntax: the upload command is the curl command.

We'll cover:

Single-file upload.
Multiple files in one request.
Mixing files with plain form fields.
Dynamic file paths through variables.
A runnable example against httpbin's echo endpoint.

The curl Syntax Refresher

# one file
curl -X POST https://api.example.com/upload -F 'file=@./photo.png'

# two files under the SAME field name
curl -X POST https://api.example.com/upload \
  -F 'files=@./a.pdf' -F 'files=@./b.pdf'

# a file plus regular form fields
curl -X POST https://api.example.com/upload \
  -F 'userId=123' \
  -F 'note=hello' \
  -F 'file=@./photo.png'

The magic marker is @: key=@path means this value is a file on disk; key=value without @ is a plain text field. JQuickCurl's parser understands exactly this convention and builds the corresponding multipart body over OkHttp.

Example 1: Single-File Upload

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;

public interface UploadApi {

    @JCurlCommand("curl -X POST 'https://httpbin.org/post' "
            + "-F 'avatar=@./profile.png'")
    String uploadAvatar(JQuickCurlReq request);
}

JQuickCurlReq req = new JQuickCurlReq();
String result = JCurlInvoker.createProxy(UploadApi.class).uploadAvatar(req);
System.out.println(result);   // httpbin echoes back the "files" section

httpbin's /post returns "files": {"avatar": "<binary content>"}, which proves the multipart body really was transmitted.

Example 2: Multiple Files Under One Field

Uploading several files at once simply repeats -F with the same key:

public interface UploadApi {

    @JCurlCommand("curl -X POST 'https://httpbin.org/post' "
            + "-F 'documents=@./report-q1.pdf' "
            + "-F 'documents=@./report-q2.pdf'")
    String uploadQuarterlyReports(JQuickCurlReq request);
}

The same pattern works for a set of related files such as images or logs. For truly arbitrary numbers of files, pair the -F command with a small loop that builds several commands or pick a fixed upper bound per call.

Example 3: File + Ordinary Form Fields (The Importer)

Real import endpoints rarely want a bare file — they want metadata alongside it. Combine fields and files freely:

public interface UploadApi {

    @JCurlCommand("curl -X POST 'https://httpbin.org/post' "
            + "-F 'uploader=${uploader}' "
            + "-F 'description=${description}' "
            + "-F 'spreadsheet=@./products.xlsx'")
    String importSpreadsheet(JQuickCurlReq request);
}

JQuickCurlReq req = new JQuickCurlReq();
req.put("uploader", "jane.doe");
req.put("description", "monthly product refresh");
req.put("spreadsheet", "./products.xlsx");
String out = api.importSpreadsheet(req);

The server receives form fields uploader and description plus file spreadsheet — everything curl's multipart encoding supports.

Example 4: Dynamic File Paths

Hard-coding a path in the annotation works, but real applications pick the file at runtime. Because -F values participate in variable substitution, the path can come from JQuickCurlReq:

@JCurlCommand("curl -X POST 'https://httpbin.org/post' "
        + "-F 'file=@${filePath}'")
String uploadFromPath(JQuickCurlReq request);

JQuickCurlReq req = new JQuickCurlReq();
req.put("filePath", "downloads/today/report.xlsx");
api.uploadFromPath(req);

Path tips: use forward slashes for portability; on Windows, backslashes inside a Java annotation string must be escaped (\\\\) or prefer /. Relative paths resolve against the process's working directory.

Complete Runnable Demo

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;
import com.github.paohaijiao.executor.JCurlInvoker;

public interface MultiUploadApi {

    @JCurlCommand("curl -X POST 'https://httpbin.org/post' "
            + "-F 'owner=${owner}' "
            + "-F 'primary=@./pom.xml' "
            + "-F 'secondary=@./README.md'")
    String uploadPair(JQuickCurlReq request);
}

class UploadDemo {
    public static void main(String[] args) {
        MultiUploadApi api = JCurlInvoker.createProxy(MultiUploadApi.class);

        JQuickCurlReq req = new JQuickCurlReq();
        req.put("owner", "team-core");

        String result = api.uploadPair(req);
        System.out.println(result);
        // Look for "form": { "owner": "team-core" } and
        // "files": { "primary": ..., "secondary": ... } in the echo.
    }
}

Run it from the project root so pom.xml and README.md exist — the demo then needs no extra setup.

When Multipart Is the Wrong Tool

Large files / resumable uploads: multipart isn't streaming-friendly for gigabytes; consider chunked or presigned-URL uploads.
Tiny key/value pairs: plain JSON or --data-urlencode is lighter than multipart.
Files already on a server: pass a URL and let the backend fetch it instead.

Summary

JQuickCurl lets your team keep using the file-upload syntax they already know from curl and Postman. -F 'key=@path' for files, -F 'key=value' for fields, repeated -F options for multi-file uploads, and ${path} variables for runtime-selected files. The multipart boundary choreography stays inside the library.

That covers sending bytes up; Post 10 flips the direction and downloads remote files straight to local disk with curl's --output flag.

java #springboot #httpclient #opensource #java-library

Conditional Requests at Runtime: Rendering Parts of a curl Command with XML ``

paohaijiao — Sun, 13 Sep 2026 23:19:04 +0000

HTTP requests are rarely static in production. A header should only be sent when a feature flag is on, verbose logging should appear only in debug sessions, and an endpoint variant should be selected by environment. JQuickCurl's XML mode solves this with conditional rendering: an <if test="..."> element whose enclosed curl text is included only when the expression evaluates to true — evaluated per request, at runtime.

This post shows:

How <if> composes with the XML catalog from Post 7.
Realistic conditions: headers, options, and body fragments.
A complete runnable demo with a toggled debug mode.

The Rule: Only What's True Gets Rendered

Inside a <curl> element you can wrap any curl fragment in <if test="expression">. If the expression holds, the fragment's text is spliced into the final command; otherwise it disappears as if never written.

<curl name="getUserByIdVariable" returnClass="com.example.model.User">
    curl -X GET #{host} \
    <if test="a == 1"> -H "Content-Type: application/json" </if>
</curl>

The expression reads values from the request context — which includes the @Param-annotated arguments you pass to the interface method (Post 7). Here, the extra header appears only when parameter a equals 1.

Practical Pattern 1: Toggle Debug Verbosity

Wrap the curl logging flag so that production traffic is silent while a debug flag on the interface adds -v:

<curls namespace="com.example.search.SearchApi">

    <curl name="search" returnClass="java.lang.String">
        curl -X GET 'https://api.example.com/search?q=#{keyword}&page=#{page}'
        <if test="debug == true"> -v </if>
    </curl>

</curls>

public interface SearchApi {
    String search(@Param("keyword") String keyword,
                  @Param("page") int page,
                  @Param("debug") boolean debug);
}

Calling search("http", 1, true) adds -v to the command; calling it with false drops it. The same request shape, one conditional branch.

Practical Pattern 2: Conditional Header Injection

Environment-sensitive headers are a perfect <if> target. Inject a tracing header only when a traceId is actually present, and an API-key header only for the private environment:

<curl name="orders" returnClass="java.lang.String">
    curl -X GET '#{host}/orders?status=#{status}'
    <if test="traceId != null and traceId != ''"> -H "X-Trace-Id: #{traceId}" </if>
    <if test="env == 'prd'"> -H "X-Env: prd" -H "Authorization: Bearer #{token}" </if>
</curl>

public interface OrderApi {
    String orders(@Param("host") String host,
                  @Param("status") String status,
                  @Param("traceId") String traceId,
                  @Param("env") String env,
                  @Param("token") String token);
}

Same method, but the wire request differs with runtime state — no if/else in Java, no empty headers being sent.

Practical Pattern 3: Choose the Payload

Conditions can also select between body fragments. Sending a body only for methods that need one:

<curl name="report" returnClass="java.lang.String">
    curl -X POST 'https://api.example.com/reports'
    -H 'Content-Type: application/json'
    -d '{"type":"#{kind}"}'
    <if test="includeFilter == true"> ,"filter":{"min":#{min}} </if>
</curl>

When splicing JSON fragments, keep the result valid JSON after substitution. Several small <if> blocks are easier to reason about than one opaque mega-expression.

Runnable Demo

Put the catalog below on the classpath as search.xml and run the Java class.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE curls PUBLIC "-//PAOHAIJIAO//DTD API CURL 1.0//EN"
        "classpath:paohaijiao/dtd/Jquick-curl.dtd">
<curls namespace="com.example.search.SearchApi">
    <curl name="search" returnClass="java.lang.String">
        curl -X GET 'https://httpbin.org/anything/search?q=#{q}'
        <if test="verbose == true"> -v </if>
        <if test="withHeader == true"> -H "X-Demo: conditional" </if>
    </curl>
</curls>

import com.github.paohaijiao.xml.JQuickCurlXmlParseFactory;
import com.github.paohaijiao.xml.factory.JQuickXmlFactory;
import com.github.paohaijiao.xml.handler.JQuickParseHandler;
import com.github.paohaijiao.xml.param.Param;

public interface SearchApi {
    String search(@Param("q") String q,
                  @Param("verbose") boolean verbose,
                  @Param("withHeader") boolean withHeader);
}

class ConditionalDemo {
    public static void main(String[] args) {
        JQuickParseHandler parser = new JQuickCurlXmlParseFactory();
        SearchApi api = new JQuickXmlFactory(parser, "search.xml").createApi(SearchApi.class);

        // Verbose + header enabled
        System.out.println(api.search("curl", true, true));

        // Both disabled — the request on the wire is different
        System.out.println(api.search("curl", false, false));
    }
}

Because the endpoint is httpbin.org/anything, the response echoes the headers and args the server actually received — you can visually confirm that X-Demo appears only in the first call.

Beyond `<if>`: The Full XML Control Set

The bundled DTD defines more than if. XML content may also use:

<foreach collection="..." item="..."> — repeat content over a collection with open, close, and separator.
<choose> / <when test="..."> / <otherwise> — multi-branch selection, similar to a switch.

Use them for the same goal: keeping the curl command truthful while letting runtime data shape it.

Summary

XML <if> turns a static curl catalog into a runtime decision graph. Headers, flags, and payload fragments are included only when their test expression is true, evaluated fresh on every invocation. The Java interface stays declarative and the request stays readable — the conditional logic lives where the request is defined, not sprinkled through callers.

Repository: dromara/jquick-curl. Post 9 covers the opposite end of HTTP payloads: binary and multipart file uploads through curl's -F flag.

java #springboot #httpclient #opensource #java-library

XML Configuration Mode: Decoupling Your API Catalog from Business Code

paohaijiao — Sat, 12 Sep 2026 23:23:45 +0000

Annotation mode keeps requests close to Java, but large integrations raise a fair question: do I want a wall of curl strings inside my service interfaces? JQuickCurl's XML mode answers with a firm no — you store every API definition in a separate XML file, and the business layer only sees plain Java interfaces with no annotations at all. This is the classic "declarative client" split: contract in configuration, behavior in code.

In this post you'll learn to:

Author an XML API catalog with the official DTD.
Bind it to a plain Java interface automatically.
Use #{...} context variables in XML.
Swap endpoint behavior without recompiling business code.

The Big Idea

apis.xml   (curl commands + return types)        business code
   |                                                  |
   +-- parsed by JQuickCurlXmlParseFactory ----------> plain interface proxy

The XML file names each request and declares its return type. The factory binds those entries to interface methods by method name. Change the curl in XML → the running app changes behavior. No Java edits, no rebuild.

Step 1: Write the XML Catalog

Save this as src/main/resources/apis.xml. The DOCTYPE references the bundled DTD so your IDE can validate structure as you type.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE curls PUBLIC "-//PAOHAIJIAO//DTD API CURL 1.0//EN"
        "classpath:paohaijiao/dtd/Jquick-curl.dtd">

<curls namespace="com.example.weather.WeatherApi">

    <curl name="current" returnClass="java.lang.String">
        curl -X GET 'https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current_weather=true'
    </curl>

    <curl name="currentAt" returnClass="java.lang.String">
        curl -X GET 'https://api.open-meteo.com/v1/forecast?latitude=#{lat}&longitude=#{lon}&current_weather=true'
    </curl>

    <curl name="sunrise" returnClass="java.lang.String">
        curl -X GET 'https://api.sunrise-sunset.org/json?lat=#{lat}&lng=#{lon}&formatted=0'
    </curl>
</curls>

Rules to remember while authoring:

<curls namespace="..."> identifies the interface the file maps to.
Each <curl> has name (must equal the Java method name) and returnClass (fully qualified).
The text content is the curl command; #{name} placeholders are resolved at runtime from context/method parameters.
Optional <if>, <foreach>, and <choose> children make content conditional (Post 8 covers <if> in depth).

Step 2: Write a Pure Java Interface

No annotations, no HTTP imports — just signatures matching the name attributes. Parameters are bound with @Param("...") (import from the xml module) so the XML can reference them via #{...}:

import com.github.paohaijiao.xml.param.Param;

public interface WeatherApi {

    String current();

    String currentAt(@Param("lat") double lat, @Param("lon") double lon);

    String sunrise(@Param("lat") double lat, @Param("lon") double lon);
}

Step 3: Build the Proxy from the XML Factory

JQuickCurl ships its own parse handler; the generic XML-proxy factory comes from the companion library:

import com.github.paohaijiao.xml.JQuickCurlXmlParseFactory;
import com.github.paohaijiao.xml.factory.JQuickXmlFactory;
import com.github.paohaijiao.xml.handler.JQuickParseHandler;

public class XmlDemo {

    public static void main(String[] args) {
        // 1. Parser that understands JQuickCurl XML.
        JQuickParseHandler parser = new JQuickCurlXmlParseFactory();

        // 2. Factory bound to the classpath resource "apis.xml".
        JQuickXmlFactory factory = new JQuickXmlFactory(parser, "apis.xml");

        // 3. One proxy for the whole catalog.
        WeatherApi api = factory.createApi(WeatherApi.class);

        System.out.println(api.current());

        System.out.println(api.currentAt(52.52, 13.41));

        System.out.println(api.sunrise(52.52, 13.41));
    }
}

Expected output: JSON from Open-Meteo and the sunrise/sunset API. The calls above run without authentication and prove the whole round trip.

A Second Catalog Without Touching Java

Want to point current at a different provider, add a header, or insert retry semantics? Edit only the XML:

<curl name="current" returnClass="java.lang.String">
    curl -X GET 'https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current_weather=true' \
    -H 'Accept: application/json'
</curl>

The proxy, the interface, and all callers stay unchanged. That is the entire value proposition: API drift is fixed in one configuration file, not across dozens of call sites.

XML Mode vs Annotation Mode — When to Choose Which

Dimension	Annotation mode (`@JCurlCommand`)	XML mode (`apis.xml`)
Request location	Next to Java code	Centralized config file
Change without rebuild	No	Yes
IDE help	Java syntax	XML + DTD validation
Variables	`${name}` from `JQuickCurlReq`	`#{name}` from context / `@Param` args
Best fit	Few endpoints, team owns the code	Large third-party API catalogs, shared config

Summary

XML configuration mode decouples what the HTTP call is from who calls it. You get one searchable, validated, DTD-checked catalog of every integration your service owns, while Java interfaces stay free of annotation noise. This pattern pays off exactly when your API surface is wide and changes often.

Source project: dromara/jquick-curl. Post 8 pushes XML mode further with <if> conditions that render parts of a request only when runtime state says so.

java #springboot #httpclient #opensource #java-library

REST in Annotation Mode: JSON GET, POST, PUT, and DELETE with @JCurlCommand

paohaijiao — Sat, 12 Sep 2026 02:11:10 +0000

After the Hello World in Post 1, it's time for the classic backend bread-and-butter: a full JSON CRUD cycle. In annotation mode each HTTP verb is just a different curl command sitting on its own interface method. We'll build a small user-management demo against the free ReqRes REST API and show four return-type styles: String, a domain object, a collection, and Void.

The curl Commands Behind Each Verb

# Read one resource (returns a JSON object)
curl -X GET https://reqres.in/api/users/2

# Create a resource (sends JSON, returns the created object with a new id)
curl -X POST https://reqres.in/api/users \
  -H 'Content-Type: application/json' \
  -d '{"name":"Ada","job":"Engineer"}'

# Replace / update a resource
curl -X PUT https://reqres.in/api/users/2 \
  -H 'Content-Type: application/json' \
  -d '{"name":"Ada Lovelace","job":"Analyst"}'

# Delete a resource (returns an empty body, HTTP 204)
curl -X DELETE https://reqres.in/api/users/2

Every one of these strings is a valid @JCurlCommand value — no request-builder API involved.

The CRUD Interface

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;

public interface UserCrudApi {

    @JCurlCommand("curl -X GET 'https://reqres.in/api/users/${id}'")
    String getUser(JQuickCurlReq request);

    @JCurlCommand("curl -X POST 'https://reqres.in/api/users' "
            + "-H 'Content-Type: application/json' "
            + "-d '{\"name\":\"${name}\",\"job\":\"${job}\"}'")
    String createUser(JQuickCurlReq request);

    @JCurlCommand("curl -X PUT 'https://reqres.in/api/users/${id}' "
            + "-H 'Content-Type: application/json' "
            + "-d '{\"name\":\"${name}\",\"job\":\"${job}\"}'")
    String updateUser(JQuickCurlReq request);

    @JCurlCommand("curl -X DELETE 'https://reqres.in/api/users/${id}'")
    Void deleteUser(JQuickCurlReq request);
}

Observations:

Method name, HTTP verb, and URL are decoupled — rename methods freely.
The return type drives conversion: here String and Void (Void discards the body for DELETE).
JSON bodies use the ${...} placeholders from Post 5, so createUser and updateUser share one command shape each.

Driving the Full Cycle

import com.github.paohaijiao.domain.req.JQuickCurlReq;
import com.github.paohaijiao.executor.JCurlInvoker;

public class CrudDemo {

    public static void main(String[] args) {
        UserCrudApi api = JCurlInvoker.createProxy(UserCrudApi.class);

        // CREATE
        JQuickCurlReq create = new JQuickCurlReq();
        create.put("name", "Ada");
        create.put("job", "Engineer");
        String created = api.createUser(create);
        System.out.println("created: " + created);   // JSON incl. new id

        // READ (needs an id — parse it from the create response in real code)
        JQuickCurlReq read = new JQuickCurlReq();
        read.put("id", 2);
        System.out.println("read: " + api.getUser(read));

        // UPDATE
        JQuickCurlReq update = new JQuickCurlReq();
        update.put("id", 2);
        update.put("name", "Ada Lovelace");
        update.put("job", "Analyst");
        System.out.println("updated: " + api.updateUser(update));

        // DELETE
        JQuickCurlReq delete = new JQuickCurlReq();
        delete.put("id", 2);
        api.deleteUser(delete);
        System.out.println("deleted OK");
    }
}

Expected behavior: ReqRes is a mock API, so responses are deterministic — POST /api/users answers with the payload plus an id, and DELETE returns HTTP 204.

Beyond String: Typed Return Values

Declaring the method return type is all it takes to skip manual JSON parsing. The response converter maps the JSON body onto your class — mirror the response keys with your fields:

public class UserInfo {
    private long id;
    private String email;
    private String name;
    private String job;

    // getters and setters omitted for brevity
}

public interface TypedCrudApi {

    @JCurlCommand("curl -X GET 'https://reqres.in/api/users/${id}'")
    UserInfo getUser(JQuickCurlReq request);

    @JCurlCommand("curl -X GET 'https://reqres.in/api/users?page=${page}'")
    java.util.List<UserInfo> listUsers(JQuickCurlReq request);
}

Other supported return types worth remembering:

Return type	Result
`String`	Raw response body as text
`byte[]`	Raw body bytes (great for binary endpoints)
Your POJO	Body JSON bound to the object
`java.util.List<T>`	JSON array bound to a list of objects
`Void`	Execute and discard the response body
`JResult` / `JQuickCurlResponseBody`	Keep the raw response with extra accessors

PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE

JQuickCurl's parser and executor cover eight methods today: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, and TRACE. PATCH follows the same pattern as PUT with a smaller payload:

@JCurlCommand("curl -X PATCH 'https://reqres.in/api/users/${id}' "
        + "-H 'Content-Type: application/json' "
        + "-d '{\"job\":\"${job}\"}'")
String patchUser(JQuickCurlReq request);

HEAD and OPTIONS usually return no meaningful body — return Void — and TRACE is a bodyless diagnostic verb on the executor side.

Summary

CRUD in annotation mode is literally your tested curl commands with the volatile values promoted to ${...} placeholders. Method naming, return-type conversion (String, POJO, List, Void, byte[], …), and header handling are all declarative. This is the pattern the rest of the series builds on — XML configuration, conditionals, uploads, and downloads are just more curl commands wearing different clothes.

Everything here runs against the open-source dromara/jquick-curl. Post 7 shows the same idea, but with API definitions lifted out of Java entirely and into XML.

java #springboot #httpclient #opensource #java-library

Deep Dive into @JCurlCommand: The Annotation and Its Variable Substitution Grammar

paohaijiao — Thu, 10 Sep 2026 22:36:17 +0000

@JCurlCommand is the heart of JQuickCurl's annotation mode. One annotation turns a static curl string into a dynamic, typed HTTP method. This post covers the annotation's full surface and — more importantly — the ${...} variable grammar that makes one command reusable across thousands of runtime states.

The Annotation, Decoded

@JCurlCommand targets methods and is retained at runtime so the proxy layer can read it on every invocation:

In practice you will use value() on every method; the other attributes give you a declarative place to document the response contract for a command. The empty constructor proxy flow rejects methods annotated with execute = false, so treat execute as "this annotation is a real executable command".

public interface HealthApi {

    @JCurlCommand(
        value = "curl -X GET https://httpbin.org/status/200"
    )
    String ping(JQuickCurlReq request);
}

The `${name}` Variable Grammar

JQuickCurl embeds variables inside the curl string using ${name}. At execution time the proxy:

Collects the keys you put into JQuickCurlReq.
Copies them into the request context (JContext).
Replaces every ${name} occurrence with the corresponding runtime value.

Because substitution happens before the HTTP call, you can place placeholders anywhere syntax allows — URL path, query string, header value, auth pair, or request body.

URLs and Paths

public interface GithubLikeApi {

    @JCurlCommand("curl -X GET 'https://api.example.com/repos/${owner}/${repo}/issues/${issueId}'")
    String getIssue(JQuickCurlReq request);
}

// Usage
JQuickCurlReq req = new JQuickCurlReq();
req.put("owner", "dromara");
req.put("repo", "jquick-curl");
req.put("issueId", 42);
String issue = proxy.getIssue(req);   // GET /repos/dromara/jquick-curl/issues/42

Query Strings

@JCurlCommand("curl -X GET 'https://api.example.com/search?q=${query}&page=${page}&size=${size}'")
String search(JQuickCurlReq request);

JQuickCurlReq req = new JQuickCurlReq();
req.put("query", "http client");
req.put("page", 2);
req.put("size", 20);

Headers and Authentication Pairs

Variables are not limited to URLs — credentials belong there too, so secrets never sit in source code:

public interface AuthApi {
    @JCurlCommand("curl -X GET 'https://api.example.com/me' "
            + "-H 'Authorization: Bearer ${token}'")
    String currentUser(JQuickCurlReq request);

    @JCurlCommand("curl -u '${user}:${password}' https://api.example.com/account")
    String account(JQuickCurlReq request);
}

JQuickCurlReq req = new JQuickCurlReq();
req.put("token", System.getenv("API_TOKEN"));   // never hard-code secrets
req.put("user", "demo");
req.put("password", System.getenv("API_PASSWORD"));

Request Bodies

When the JSON body must change per call, build it in Java and substitute it:

@JCurlCommand("curl -X POST 'https://api.example.com/orders' "
        + "-H 'Content-Type: application/json' "
        + "-d '${payload}'")
String createOrder(JQuickCurlReq request);

String payload = "{\"customer\":\"Ada\",\"amount\":99.5,\"items\":[1,2,3]}";
JQuickCurlReq req = new JQuickCurlReq();
req.put("payload", payload);

Careful: the body is inserted verbatim, so the JSON must already be valid (quotes, braces, commas) before substitution.

Method Parameters as Variables (Alternative Style)

Besides the JQuickCurlReq map, JQuickCurl can substitute ${name} from method parameter names when a method declares extra parameters — the placeholder must equal the Java parameter's name. This gives you compiler-visible signatures for static call sites:

public interface OrderApi {
    @JCurlCommand("curl -X GET 'https://api.example.com/orders/${orderId}'")
    String getOrder(JQuickCurlReq request);
}

For dynamic multi-value cases the map style is far more flexible, which is why the rest of this series standardizes on JQuickCurlReq.

Quoting Rules and Escaping Cheat-Sheet

What you write	Meaning
`'https://…/${id}'`	Single-quoted value with a variable — preferred style
`"Authorization: Bearer ${token}"`	Double-quoted value; you must escape as `\"` inside a Java annotation
`-d '{"a":1}'`	Body with double quotes → escape them in Java: `"{\"a\":1}"`
`${key}` with a missing key	Left unresolved — the request context simply has no such entry

If a response surprises you, first check whether the placeholder key actually made it into JQuickCurlReq before the call (see Post 17's troubleshooting checklist).

Runnable Demo

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;
import com.github.paohaijiao.executor.JCurlInvoker;

public interface EchoApi {
    @JCurlCommand("curl -X GET 'https://httpbin.org/anything/${channel}?trace=${traceId}' "
            + "-H 'X-Scope: ${scope}'")
    String call(JQuickCurlReq request);
}

class VariableDemo {
    public static void main(String[] args) {
        EchoApi api = JCurlInvoker.createProxy(EchoApi.class);

        JQuickCurlReq req = new JQuickCurlReq();
        req.put("channel", "mobile");
        req.put("traceId", "trc-9911");
        req.put("scope", "readonly");

        System.out.println(api.call(req));
        // httpbin echoes url, headers, args — showing every variable resolved.
    }
}

Summary

@JCurlCommand provides the executable surface (the curl string) and a small set of contract attributes, while ${name} placeholders supply the dynamism. Variables work anywhere in the command — path, query, headers, auth, and bodies — and their values come from the same JQuickCurlReq map that every method in this series already uses. Combined with the proxy pattern, one annotated command now serves an unlimited number of runtime requests.

Repository: dromara/jquick-curl. Post 6 applies this knowledge to the full REST alphabet — JSON GET, POST, PUT, and DELETE in annotation mode.

java #springboot #httpclient #opensource #java-library

Stop Translating: Reuse Postman and Browser-Copied curl Fragments Directly in Java

paohaijiao — Wed, 09 Sep 2026 22:20:17 +0000

"How did you test that endpoint?" — "I copied the curl from Postman." That sentence is why JQuickCurl exists. When a request works in Postman or the browser DevTools, the raw curl fragment is already the ground truth. In this post you'll learn a repeatable recipe:

Export curl from Postman or copy it from Chrome DevTools.
Sanitize it (remove volatile headers and secrets).
Paste it into @JCurlCommand.
Turn the moving parts into ${...} variables.
Run the exact same request from Java.

Step 1: Get the curl Snippet

From Postman: open your saved request → the </> Code button in the top-right → choose cURL → copy.

From Chrome DevTools: open the Network tab → right-click the request you care about → Copy → Copy as cURL (bash).

A typical browser copy looks like this (notice the noise):

curl 'https://api.example.com/orders/1024' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-US,en;q=0.9' \
  -H 'cookie: _ga=GA1.2.abc; session=7f3a9c1e...' \
  -H 'sec-ch-ua: "Chromium";v="120", "Google Chrome";v="120"' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 ...'

Step 2: Sanitize Before You Paste

Rule number one of reusing curl in server code: the browser context is not your server context. Remove or externalize:

cookie / authorization values (inject them at runtime instead — see Post 12 on interceptors).
Browser fingerprint headers (sec-ch-ua, sec-fetch-*, user-agent) unless the API genuinely validates them.
Your _ga tracking cookies — you do not want analytics cookies in server logs.

Keep the semantic core: method, URL, Content-Type, real payload, and any header the API contract actually requires.

Step 3: Paste into an Annotation — and Mind the Escaping

Collapse the multi-line shell command onto one line and put it inside @JCurlCommand:

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;

public interface OrderApi {

    @JCurlCommand("curl -X GET 'https://api.example.com/orders/1024' "
            + "-H 'accept: application/json' "
            + "-H 'X-Client: jquick-curl'")
    String getOrder(JQuickCurlReq request);
}

Java-string escaping rules are the only friction you'll meet:

Postman/browser use double quotes in headers (-H "Accept: ..."); inside an annotation they must be escaped or switched to single quotes. I recommend single quotes — they read cleanly and match shell-style curl.
If your JSON body itself contains single quotes, escape them with \' inside the single-quoted value, or keep double quotes and escape them as \".

Tip: concatenating adjacent string literals ("..." + "...") keeps long commands readable and still satisfies Java's requirement that annotation values be compile-time constants.

Step 4: Make the Moving Parts Dynamic

A hard-coded order ID dies on the first real request. Replace volatile values with ${name} placeholders and supply them through JQuickCurlReq:

public interface OrderApi {

    @JCurlCommand("curl -X GET 'https://api.example.com/orders/${orderId}' "
            + "-H 'accept: application/json'")
    String getOrder(JQuickCurlReq request);
}

JQuickCurlReq request = new JQuickCurlReq();
request.put("orderId", 1024);
String json = JCurlInvoker.createProxy(OrderApi.class).getOrder(request);
System.out.println(json);

JQuickCurlReq is literally a HashMap<String, Object>, so put/get behave exactly as you'd expect. Whatever key you place there can be referenced as ${key} anywhere in the command — URL, header value, -u credentials, -d body.

Step 5: Full "Pasted from Postman" Demo

Here's a complete runnable example using the public httpbin echo service. Copy this curl from your own Postman and you can verify the flow end-to-end:

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;
import com.github.paohaijiao.executor.JCurlInvoker;

public interface PostmanApi {

    // The exact command you exported, after removing volatile headers.
    @JCurlCommand("curl -X POST 'https://httpbin.org/post' "
            + "-H 'Content-Type: application/json' "
            + "-d '{\"orderId\":${orderId},\"customer\":\"${customer}\"}'")
    String postOrder(JQuickCurlReq request);
}

class Demo {
    public static void main(String[] args) {
        PostmanApi api = JCurlInvoker.createProxy(PostmanApi.class);

        JQuickCurlReq req = new JQuickCurlReq();
        req.put("orderId", 555);
        req.put("customer", "Hashnode reader");

        System.out.println(api.postOrder(req));
        // httpbin echoes back the "data" field containing your substituted JSON.
    }
}

What If the Pasted Command Fails to Parse?

JQuickCurl's parser targets the curl options its test suite covers. Before debugging your own code, double-check that the exported snippet only uses these option families: -X/--request, -H/--header, -d/--data(-ascii|-binary|-raw|-urlencode), -u/--user, -L/--location/--max-redirs, -F/--form, -o/--output, -x/--proxy/--socks5-hostname, plus --http2, -k/--insecure, -v/--verbose, -s/--silent. Exotic flags (--compressed, --resolve, --path-as-is, …) are not part of the supported set — strip them from the fragment you paste.

Summary

The workflow that used to take "translate request → write builder code → pray" now takes seconds: copy curl → sanitize → paste → parameterize. JQuickCurl closes the gap between the tool where you debug HTTP (Postman/browser) and the code where you ship it. All examples in this series run against dromara/jquick-curl.

Next up, in Post 5, we take a deep dive into the @JCurlCommand annotation and its variable-substitution grammar — the feature that turns static curl strings into dynamic production requests.

java #springboot #httpclient #opensource #java-library

JQuickCurl vs OkHttp vs RestTemplate vs OpenFeign: A Honest Comparison for Backend Engineers

paohaijiao — Tue, 08 Sep 2026 23:26:21 +0000

Choosing an HTTP client is a "boring but expensive" decision: it touches every downstream integration you own. OkHttp, Spring's RestTemplate, OpenFeign, and now curl-driven JQuickCurl all work — the real question is who should write and maintain your request definitions. This post compares the four on the dimensions that actually matter in a backend codebase, then gives you a decision framework.

The Contenders in One Line Each

Client	Request definition style	Best for
OkHttp	Hand-written `Request.Builder` code	Low-level control, streaming, custom protocols, performance-critical paths
RestTemplate	Hand-written URIs + `HttpEntity`/`HttpHeaders`	Classic Spring MVC codebases (deprecated in spirit by Spring in favor of WebClient)
OpenFeign	Annotated Java interfaces (`@GetMapping`, etc.)	Spring Cloud microservices with server-side (or declarative) contracts
JQuickCurl	Raw curl strings parsed by ANTLR4, plus variables & XML	Teams that live in Postman/browser curl and want zero hand-written request construction

What the Code Looks Like Side by Side

OkHttp — everything explicit, everything manual:

HttpUrl url = HttpUrl.get("https://jsonplaceholder.typicode.com/posts")
        .newBuilder()
        .addQueryParameter("userId", "1")
        .build();

RequestBody body = RequestBody.create(
        "{\"title\":\"ok\",\"body\":\"bar\",\"userId\":1}",
        MediaType.get("application/json; charset=utf-8"));

Request request = new Request.Builder()
        .url(url)
        .addHeader("Accept", "application/json")
        .post(body)
        .build();

try (Response response = new OkHttpClient().newCall(request).execute()) {
    System.out.println(response.body() != null ? response.body().string() : "");
}

RestTemplate — annotations gone, strings everywhere:

RestTemplate rest = new RestTemplate();
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.APPLICATION_JSON);
HttpEntity<String> entity = new HttpEntity<>("{\"title\":\"ok\",\"userId\":1}", headers);

ResponseEntity<Map> resp = rest.exchange(
        "https://jsonplaceholder.typicode.com/posts?userId={id}",
        HttpMethod.POST, entity, Map.class, 1);
System.out.println(resp.getBody());

OpenFeign — contract-driven, but only if the contract exists:

@FeignClient(name = "posts", url = "https://jsonplaceholder.typicode.com")
public interface PostClient {
    @PostMapping(value = "/posts", consumes = "application/json")
    Map<String, Object> create(@RequestBody Map<String, Object> payload);
}

JQuickCurl — the tested curl snippet is the code:

public interface PostApi {
    @JCurlCommand("curl -X POST https://jsonplaceholder.typicode.com/posts "
            + "-H 'Content-Type: application/json' "
            + "-d '{\"title\":\"ok\",\"body\":\"bar\",\"userId\":1}'")
    String create(JQuickCurlReq request);
}

The differences become obvious: OkHttp/RestTemplate force you to re-describe the request in builder API; OpenFeign introduces a parallel annotation vocabulary; JQuickCurl reuses the universal curl vocabulary you already test with.

Comparison Table: What Actually Differs

Criterion	OkHttp	RestTemplate	OpenFeign	JQuickCurl
Reuse Postman/browser curl	Manual rewrite	Manual rewrite	Manual rewrite	Paste directly
Dynamic requests (headers/body per call)	Code branches	Code branches	SpEL / interceptors	Variables `${...}` + XML `<if>`
Cross-team sharing of request format	None	None	Contract stubs	Same curl string
Proxy / dynamic invocation	N/A	N/A	Yes	Yes (`createProxy`)
Timeouts/retry/pool out of the box	Builder	Some	Via config	Global `JQuickCurlConfig`
Multipart upload / download	Manual	Manual	Manual	`-F` / `--output` in curl
Spring Cloud integration	No	Native template	Native	Bean wiring (manual, simple)
Dependency weight	Small	Spring Web	Spring Cloud stack	OkHttp + ANTLR runtime
Learning curve for new devs	Medium	Low	Low–Medium	Low if they know curl

When to Pick JQuickCurl (Honest Scenarios)

Choose JQuickCurl when:

You or your QA team already maintain curl collections in Postman and want them as executable Java code.
Third-party OpenAPI docs ship curl samples and you must integrate many endpoints quickly (see Post 18).
You need dynamic requests that depend on runtime state (auth tokens, environment hosts, feature flags) without writing factory methods per endpoint.
You want API definitions externalized in XML, decoupled from business code.

Still choose the alternatives when:

You are deep inside the Spring Cloud ecosystem and already own Feign clients — the load-balancer/service-discovery integration is a solved problem there.
You need WebFlux/reactive non-blocking I/O — JQuickCurl's model is synchronous OkHttp calls (though OkHttp itself is async-capable under the hood).
You only have a handful of endpoints and the team knows one client cold — introducing any new abstraction has a cost.

Decision Checklist

Do your requests already exist as curl commands? → strong signal for JQuickCurl.
Do you run a microservice mesh with Feign today? → stay on Feign unless curl reuse is a bigger pain.
Do you need reactive streaming? → OkHttp/WebClient territory.
Do you want one tool for the whole team to read requests? → JQuickCurl wins on readability.

Summary

None of these tools is universally "best". OkHttp is the raw engine, RestTemplate the legacy workhorse, OpenFeign the Spring-Cloud native, and JQuickCurl the only one that treats curl as a first-class, shareable request language. JQuickCurl is not a replacement for a full service-discovery stack — it's an alternative to hand-writing request builders, and in curl-heavy, integration-heavy codebases it removes a surprising amount of boilerplate. Source: dromara/jquick-curl.

In Post 4 we'll do something every backend dev needs: reuse curl snippets exported straight from Postman and the browser, without translating them by hand.

java #springboot #httpclient #opensource #java-library

JQuickCurl Meets Spring Boot: Turn Raw curl into Injectable HTTP Beans in 10 Minutes

paohaijiao — Tue, 08 Sep 2026 11:57:46 +0000

Spring Boot developers reach for RestTemplate or WebClient out of habit, but they're both still imperative builders: you hand-code the URL, the headers, and the body every single time. JQuickCurl brings a different workflow into your Spring Boot project — you define HTTP calls as curl commands on an interface, and Spring treats that interface's proxy like any other bean you can @Autowired.

This tutorial walks through a real Spring Boot setup step by step:

Adding the dependency.
Declaring a curl-powered service interface.
Exposing the proxy as a Spring bean.
Loading global HTTP settings from a properties file.
Calling everything from a @RestController.

Note: JQuickCurl ships as a plain library (no Spring Boot starter yet). Wiring it as a @Configuration bean is a few lines of code and keeps full control in your hands.

Step 1: Dependencies

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.2.5</version>
    <relativePath/>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>io.github.paohaijiao</groupId>
        <artifactId>jquick-curl</artifactId>
        <version>2.5.0</version>
    </dependency>
</dependencies>

Step 2: Declare a curl-Driven Service Interface

We call the public JSONPlaceholder API to fetch a "todo" item. Note the signature convention: the method receives a JQuickCurlReq, and its return type is a domain object.

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;

public interface TodoApi {

    @JCurlCommand("curl -X GET https://jsonplaceholder.typicode.com/todos/1")
    TodoBean getTodo(JQuickCurlReq request);

    @JCurlCommand("curl -X POST https://jsonplaceholder.typicode.com/todos "
            + "-H 'Content-Type: application/json' "
            + "-d '{\"title\":\"learn jquick-curl\",\"completed\":false}'")
    TodoBean createTodo(JQuickCurlReq request);
}

A couple of Java-syntax tricks used above that will save you headaches:

Concatenated string literals are compile-time constants, so they're perfectly valid inside annotations — long curl commands stay readable.
Inner double quotes inside the JSON body must be escaped (\"), exactly as in any Java string.

The domain bean is a plain POJO (the response converter maps JSON onto its fields):

public class TodoBean {
    private long userId;
    private long id;
    private String title;
    private boolean completed;

    // getters and setters omitted for brevity
}

Step 3: Register the Proxy as a Spring Bean

JCurlInvoker.createProxy() returns a JDK proxy of your interface. We turn that into a singleton bean, so every controller or service can @Autowired TodoApi and the proxy — and its OkHttp transport — is created only once.

import com.github.paohaijiao.config.JQuickCurlConfig;
import com.github.paohaijiao.executor.JCurlInvoker;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class HttpApiConfig {

    // Optional: apply global HTTP settings (timeouts, pool, retry) at startup.
    public HttpApiConfig() throws Exception {
        JQuickCurlConfig.getInstance()
                .loadFromClasspathResource("quick-curl.properties");
    }

    @Bean
    public TodoApi todoApi() {
        return JCurlInvoker.createProxy(TodoApi.class);
    }
}

JQuickCurlConfig is a process-wide singleton; the fluent builders below are also available if you prefer code over properties:

JQuickCurlConfig.getInstance()
        .connectTimeout(3, TimeUnit.SECONDS)
        .readTimeout(10, TimeUnit.SECONDS)
        .writeTimeout(10, TimeUnit.SECONDS)
        .maxRetryCount(2)
        .followRedirects(true);

Step 4: Properties-Driven Tuning

Place src/main/resources/quick-curl.properties on the classpath and load it with loadFromClasspathResource(...) (keys shown here are the ones this API reads today):

quick.curl.connect.timeout=3000
quick.curl.read.timeout=10000
quick.curl.write.timeout=10000
quick.curl.pool.max.idle=20
quick.curl.pool.keep.alive=300000
quick.curl.max.retry.count=2

Now your non-functional requirements (timeouts, connection pool, retry budget) live in configuration while your request definitions live in code — no more hunting for magic numbers inside service classes.

Step 5: Consume the Bean from a Controller

import com.github.paohaijiao.domain.req.JQuickCurlReq;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class TodoController {

    private final TodoApi todoApi;

    public TodoController(TodoApi todoApi) {
        this.todoApi = todoApi;
    }

    @GetMapping("/api/todos/1")
    public TodoBean getTodo() {
        return todoApi.getTodo(new JQuickCurlReq());
    }

    @PostMapping("/api/todos")
    public TodoBean createTodo() {
        return todoApi.createTodo(new JQuickCurlReq());
    }
}

Start the application and test it:

mvn spring-boot:run
curl http://localhost:8080/api/todos/1

Response:

{"userId":1,"id":1,"title":"delectus aut autem","completed":false}

The controller stays clean: no RestTemplate, no URL constants, no header maps — the HTTP knowledge is encapsulated in @JCurlCommand annotations.

Summary

Integrating JQuickCurl into Spring Boot only requires three small pieces: a curl-annotated interface, one @Configuration class that exports its proxy as a bean, and an optional properties load for global tuning. From there, @Autowired works exactly as it does with any Spring-managed HTTP abstraction.

For a complete series context, all examples build on the dromara/jquick-curl project (Apache-2.0). In Post 3 we compare JQuickCurl against OkHttp, RestTemplate, and OpenFeign so you can decide, with evidence, when it deserves a place in your architecture.

java #springboot #httpclient #opensource #java-library

Say Goodbye to Hand-Written HTTP Code

paohaijiao — Mon, 07 Sep 2026 13:41:12 +0000

Say Goodbye to Hand-Written HTTP Code: Run Your curl Command Directly in Java with JQuickCurl

Every backend engineer knows the drill: you spend ten minutes in Postman or the browser DevTools crafting the perfect request, click "Copy as cURL", and then… stare at the screen. You have to manually translate headers, query strings, JSON bodies, and timeouts into OkHttp builders, RestTemplate exchanges, or HttpClient request objects. Translation bugs sneak in, the code balloons, and nobody wants to maintain it.

JQuickCurl (a Dromara open-source project) takes the opposite approach: the curl command itself becomes your request definition. You paste curl syntax into a Java annotation, declare an interface, and call it like a local method. The library parses your curl command with ANTLR4, executes it over the battle-tested OkHttp transport layer, and converts the response into whatever Java type you ask for.

In this first post of the series you will:

Learn what JQuickCurl is and when it shines.
Add the dependency with Maven.
Write a complete Hello-World example.
Understand what happens behind the scenes (spoiler: no system curl binary is ever spawned).

What Exactly Is JQuickCurl?

JQuickCurl is a curl-command-driven HTTP client framework for Java, licensed under Apache-2.0. Its core idea: reuse the same curl snippets your frontend, QA, and API docs already share.

Layer	Technology
curl syntax parsing	ANTLR4 (in-process, no `ProcessBuilder`)
HTTP transport	OkHttp 4.x (connection pool, HTTP/2, interceptors)
Request definition	`@JCurlCommand` annotation and XML files
Dynamic behavior	`${...}` variable substitution, XML `<if>` conditions
Extra features	file upload/download, batch execution, retry, timeouts, interceptors, dynamic proxy

Because parsing happens inside the JVM, JQuickCurl never calls the system curl binary. That means the same Java code works on Windows, Linux, and macOS, needs no external installation, and keeps full programmatic control over the request lifecycle.

Step 1: Add the Maven Dependency

Add this to your pom.xml (check Maven Central for the newest release; the examples here use 2.5.0):

<dependency>
    <groupId>io.github.paohaijiao</groupId>
    <artifactId>jquick-curl</artifactId>
    <version>2.5.0</version>
</dependency>

Step 2: Declare Your First curl-Powered API

Create an interface and put a raw curl command inside @JCurlCommand. The only "parameter convention" you need today is a JQuickCurlReq — a simple HashMap<String, Object> that carries variables for the command (more on that in a later post).

import com.github.paohaijiao.anno.JCurlCommand;
import com.github.paohaijiao.domain.req.JQuickCurlReq;

public interface EchoApi {

    // Any curl command starting with "curl" works as the annotation value.
    @JCurlCommand("curl -X GET https://httpbin.org/get")
    String get(JQuickCurlReq request);
}

Step 3: Run It from a `main` Method

JCurlInvoker.createProxy(Class) builds a JDK dynamic proxy for your interface. Every call on that proxy parses the annotation's curl command, executes it, and converts the HTTP response body into the method's return type.

import com.github.paohaijiao.domain.req.JQuickCurlReq;
import com.github.paohaijiao.executor.JCurlInvoker;

public class HelloCurl {

    public static void main(String[] args) {
        // 1. Create the proxy once — it is cheap and reusable.
        EchoApi api = JCurlInvoker.createProxy(EchoApi.class);

        // 2. An empty request map for a command without variables.
        JQuickCurlReq request = new JQuickCurlReq();

        // 3. Call your interface method like a local Java method.
        String body = api.get(request);

        System.out.println("HTTP response body:");
        System.out.println(body);
    }
}

Compile and run:

mvn compile exec:java -Dexec.mainClass=HelloCurl

You will see httpbin's JSON echo — the args, headers, and url that your request actually sent:

{
  "args": {},
  "headers": {
    "Accept-Encoding": "gzip",
    "Host": "httpbin.org",
    "User-Agent": "okhttp/4.10.0"
  },
  "url": "https://httpbin.org/get"
}

That's the whole point: the request was described by curl syntax, yet executed by OkHttp in-process.

What Just Happened Under the Hood?

Three stages, all inside your JVM:

Parse — ANTLR4 lexes and parses the annotation string curl -X GET https://httpbin.org/get into an abstract syntax tree of HTTP method, URL, headers, data, and options.
Build & execute — a visitor walks the tree and produces a real OkHttp Request; the executor sends it through OkHttp's client (connection pool, timeouts, retries, and interceptors included).
Convert — the raw response body is converted to the declared return type. Here it's String, but byte[], InputStream, custom POJOs, collections, JResult, and raw JQuickCurlResponseBody are all supported.

No curl process, no shell, no command injection risk.

Why Backend Teams Care

Zero translation bugs: the command in your code is byte-for-byte the one you tested in Postman.
One format for everyone: product docs, curl examples, and Java code stay in sync.
Configurable where it counts: timeouts, proxies, and retries can be layered on top without rewriting the request.
Lightweight: Apache-2.0, pure Java, no external runtime.

Summary

JQuickCurl lets you declare HTTP calls the way you already think about them — as curl commands. In roughly ten lines of Java you have a typed, proxy-based HTTP client with no request-building boilerplate. The Hello-World example above is the smallest building block of a much larger toolkit: dynamic variables, XML API catalogs, conditional rendering, file transfer, batch runs, interceptors, and authentication are all covered in the upcoming posts of this series.

Bookmark the repository — dromara/jquick-curl — and stay tuned for Post 2, where we wire this into a real Spring Boot application.

java #springboot #httpclient #opensource #java-library

DEV Community: paohaijiao

From Copy-Pasting curl Commands to Building My Own Java Parser (jquick-curl)

The Slack message that started it all

Why I didn't just reach for an existing tool

Designing jquick-curl

What it actually looks like

Where I'd be lying if I said this solves everything

Try it, break it, tell me

Interceptors That Actually Help: Request Logging and Automatic Bearer-Token Injection

Interceptors That Actually Help: Request Logging and Automatic Bearer-Token Injection

The Interceptor Model in One Paragraph

Built-In Logging: JLoggingInterceptor

Writing a Purpose-Built Logging Interceptor

Automatic Bearer-Token Injection

Runnable Demo

Ordering and Pitfalls

Summary

java #springboot #httpclient #opensource #java-library

Downloads Without Boilerplate: Saving HTTP Responses to Local Disk with `--output`

Approach 1: Let the Command Write the File

Approach 2: Return the Bytes and Save in Java

Directory Setup and Path Conventions

Complete Runnable Demo

Summary

java #springboot #httpclient #opensource #java-library

Multipart Uploads Made Simple: Sending Files with curl's `-F` Flag in Java

The curl Syntax Refresher

Example 1: Single-File Upload

Example 2: Multiple Files Under One Field

Example 3: File + Ordinary Form Fields (The Importer)

Example 4: Dynamic File Paths

Complete Runnable Demo

When Multipart Is the Wrong Tool

Summary

java #springboot #httpclient #opensource #java-library

Conditional Requests at Runtime: Rendering Parts of a curl Command with XML ``

The Rule: Only What's True Gets Rendered

Practical Pattern 1: Toggle Debug Verbosity

Practical Pattern 2: Conditional Header Injection

Practical Pattern 3: Choose the Payload

Runnable Demo

Beyond <if>: The Full XML Control Set

Summary

java #springboot #httpclient #opensource #java-library

XML Configuration Mode: Decoupling Your API Catalog from Business Code

The Big Idea

Step 1: Write the XML Catalog

Step 2: Write a Pure Java Interface

Step 3: Build the Proxy from the XML Factory

A Second Catalog Without Touching Java

XML Mode vs Annotation Mode — When to Choose Which

Summary

java #springboot #httpclient #opensource #java-library

REST in Annotation Mode: JSON GET, POST, PUT, and DELETE with @JCurlCommand

The curl Commands Behind Each Verb

The CRUD Interface

Driving the Full Cycle

Beyond String: Typed Return Values

PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE

Summary

java #springboot #httpclient #opensource #java-library

Deep Dive into @JCurlCommand: The Annotation and Its Variable Substitution Grammar

The Annotation, Decoded

The ${name} Variable Grammar

URLs and Paths

Query Strings

Headers and Authentication Pairs

Request Bodies

Method Parameters as Variables (Alternative Style)

Quoting Rules and Escaping Cheat-Sheet

Runnable Demo

Summary

java #springboot #httpclient #opensource #java-library

Stop Translating: Reuse Postman and Browser-Copied curl Fragments Directly in Java

Step 1: Get the curl Snippet

Step 2: Sanitize Before You Paste

Step 3: Paste into an Annotation — and Mind the Escaping

Step 4: Make the Moving Parts Dynamic

Step 5: Full "Pasted from Postman" Demo

What If the Pasted Command Fails to Parse?

Built-In Logging: `JLoggingInterceptor`

Beyond `<if>`: The Full XML Control Set

The `${name}` Variable Grammar

Step 3: Run It from a `main` Method