not all POST request have JSON bodies, we should think of a design that doesn't enforce json, but allows the user to specify the body format.

Yes that's possible. The mirror design in response body's is that we have text with arbitrary mime types, files with mime types decided by file extension and JSON values as arbitrary serialized rascal values. That seems to be general enough.

I don't really like this pattern of starting a separate thread just to invert the stream direction. Looking at the BodyPublishers, it should be okayish to write a class that wraps a ByteBuffer around a buffer that's getting flushed.

Here is such an implementation:

public class OutputStreamBodySupplier extends BufferedOutputStream implements BodyPublisher {
    private final List<Subscriber<? super ByteBuffer>> subscribers;
    
    public OutputStreamBodySupplier() {
        super(new PublishingStream());
        this.subscribers = ((PublishingStream)super.out).subscribers;
    }
    
    /**
     * The buffed outputstream will take care to collect the bytes untill there's a decent chunk to forward to the consumers
     */
    private static class PublishingStream extends OutputStream {
        private final List<Subscriber<? super ByteBuffer>> subscribers = new CopyOnWriteArrayList<>();

        @Override
        public void write(int b) throws IOException {
            for (var sub: subscribers) {
                sub.onNext(ByteBuffer.wrap(new byte[] { (byte)(b & 0xFF) }));
            }
        }

        @Override
        public void write(byte[] b, int off, int len) throws IOException {
            for (var sub: subscribers) {
                sub.onNext(ByteBuffer.wrap(b, off, len).asReadOnlyBuffer());
            }
        }

        @Override
        public void close() throws IOException {
            for (var sub: subscribers) {
                sub.onComplete();
            }
        }
    }

    @Override
    public void subscribe(Subscriber<? super ByteBuffer> subscriber) {
        this.subscribers.add(subscriber);
    }

    @Override
    public long contentLength() {
        return -1;
    }
}

Me too. Thanks for the code!

the encoding should be set for the writer, and the same encoding should also be set in the http headers.

nit: the writer will close os/out no need to add that to the try with resources.

I'm missing the option to set headers in the request, quite some API's require this.

That's provided in the Content module. Here you see only the things we need extra to make the client api work. The goal is to make Request and Response be shared as much as possible between server and client API.

okay, but I'm also missing that mapping in the java side. that's why I remarked that here.

ok cool. will fix that

Shouldn't this also change the content type to application/json?

Yes and also there are missing parameters for the headers, query, etc.

content-type is missing?

That should be one of the header settings in the keyword field of this constructor. I'll check.

missing content-type?