Roland Tepp

yes @xkr47 that would probably be necessary. Let me just outline the general plan in the following comments. The modest beginnings are already in the branch `http-api-refactor`.

## Inconsistent Request Uri API between Server and Client requests Currently the situation is that while _client Request_ uses URI for request URI, path and query arguments, the _server Request_...

@bjansen What about: ``` ceylon if (nonempty params = req.queryParameters("foo")) { value param = params.first; } ``` In any case -- if and when the server request has proper `shared...

@olegnekludov > Sorry for some offtopic, but do you have plans to implement async http client in sdk (may be create issue for that)? `ceylon.http.server` already has async endpoint implementation....

Using the well known header names is not a viable work-around either, as many services have their own slew of custom headers.

To be more precise. Currently `ceylon.http.server.Request` class has two methods: ``` ceylon shared interface Request { ... "Returns a single header with given name." shared formal String? header(String name); "Returns...

yeah ... I guess we should make it consistent. But that is backwards incompatible change!

Okay, there are few issues brough up here that are somewhat intertwined: 1. API between `ceylon.http.server` and `ceylon.http.client` in inconsistent. 2. Neither library offers an easy way to enumerate over...

It should be an easy fix, but it will break API compatibility in a big way. We should have probably fixed this while we moved the API from `ceylon.net` module...

My take on this is that if we do integrate with JUnit, we should aim for compatibility/integration with _JUnit 5/Jupiter_ as a [`TestEngine`][1] implementation. [1]: http://junit.org/junit5/docs/current/api/org/junit/platform/engine/TestEngine.html