As far as I can see, an RDAP request is a simple HTTP request, looking like http://example.com/rdap/ip/192.0.2.0. Web servers still support HTTP/1.1 (or probably even HTTP/1.0 and HTTP/0.9). This is trivial to implement for clients. A simple HTTP request like that is about he simplest thing to do. You'll have to use curl or wget instead of netcat if you want to do it manually. No big deal.

"A JS-derived serialization format" ... You mean JSON, which is about the lowest common denominator in Internet data exchange these days (and has been ever since we found out that XML was overly complex and JSON was much easier to use). You'll have to use something like jq instead of grep to extract information from the data manually. Or rather, you'll be able to use the powers of jq. Again, I don't really see the problem here.

I did not mean that there is a problem with it, only that I appreciate the simplicity of WHOIS. While HTTP-with-JSON is perhaps the most practical solution these days.

To clarify my point of view, an ad hoc HTTP client for this indeed should not be hard to write from scratch, demonstrating that there is not much complexity in that. The server part would be a little more tricky; still doable, but not as easily as for WHOIS, and in most cases a more sensible approach would be to use libraries (or a program like curl, in case of shell scripting or manual usage) for that, as you said. Likewise with JSON: though one can deal with it as with text, some added tools (a library or jq, depending on context) would be sensible to use. But then added dependencies lead to all kinds of issues in non-ideal conditions (e.g., when it is problematic to install those). But again, I am not saying that this should stop adoption of RDAP.

On top of that, a complete and proper HTTP 1.1 implementation, server or client, would be quite large. And JSON, while indeed common and not particularly complicated, still has bits I find awkward (no sum types or a standard way to encode those, but has "objects", arbitrary-looking primitive types; no single standard for streaming, either), so working around it is not exactly pleasurable. Those add up to a difference between a trivial protocol and, well, a non-trivial one. I appreciate such trivial yet working and useful solutions, though the other kind is commonly useful as well.

  curl -s https://rdap.verisign.com/com/v1/domain/example.com|jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'

And https://data.iana.org/rdap/dns.json to find the endpoints for TLDs.

Also, a large number of command line RDAP clients output plain text instead of JSON if you ask nicely.

It's a bit unreasonable, IMO, to criticize the fact that RDAP communicates using a JSON API -- while JSON is inexorably related to JavaScript (and it's not without its issues), it's ubiquitous on the modern web for serializing data, in any even vaguely REST-shaped API.

You could argue that a more compact, binary, wire format is more appropriate (though I wouldn't, in this case, since for small, simple payloads, I think simplicity and human readability trumps sheer wire efficiency). You could argue that JSON's a poor serialization language in general (which is debatable, contextual, and in this case, I don't think there's a widely-accepted better option).

But let's not act like "a JS-derived serialization format" is some kind of mark of the beast here.