Unify HttpClient and XMLHttpRequest interfaces

[sethladd]

Early feedback from hackathon: unclear what code runs on client or server.

To start, we can create a high level interface for both HttpClient and XMLHttpRequest so that there is one way to connect to web servers for the most general cases.

[DartBot]

This comment was originally written by [email protected]

---

I was trying to build a library that would need to make some GET and POST requests to a API server, since I was a Javascript developer the first thing I tried was to use the dart:dom/dart:html XMLHttpRequest to make it. When I ran my code I got this error "Do not know how to load 'dart:dom'". Then I asked for this on the IRC channel and Seth Ladd said I should use dart:io's HttpClient for server applications because dart:dom/dart:html are only for web client applications.

It will be better if there was a bit more clarification about which libraries run on server and which run on the client, or merge them into a single library.

[DartBot]

This comment was originally written by @seaneagan

---

I need this! I am writing a date/time library with i18n support which I want to make available on client and server. To do this, I need to make http requests for the cldr/i18n data for the user's specific locale, but it's currently impossible to write code for this that works on both the client and server.

This could probably be marked as blocking issue #1324 which is about removing the overlap between dart:io and dart:html as a whole.

[sgjesse]

Added this to the Later milestone.

[sethladd]

See also issue #4377

[jbdeboer]

Issue #10750 has been merged into this issue.

[sgjesse]

This will most likely be handled by an additional library in a package.

---

Removed Area-IO label.
Added Area-Pkg label.

[kasperl]

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

[sethladd]

This may happen, but no active work.

---

Added NotPlanned label.

[DartBot]

This comment was originally written by @seaneagan

---

note that issue #20068 pretty nicely solves the underlying use case though