This is also an annoying issue for us, we had to create a redirect proxy on an external server (because ONLY domains that do not contain *.lithium.com can be entered into the allowed domain names field in Admin) that would simply forward whatever endpoint-generated request it receives to the Lithium API, like this we could circumvent this (tbh insane) limitation but it's far from reasonable or nice and the reasons behind not allowing the http.client to call the Lithium APIs are unclear to us as well, maybe SuzieH or DougS could give us some insight into that descision?
The main issue I see with not allowing this is that if we want to implement AJAX enhanced community features, let's say giving a kudo to a post via API v2 (with v1 you can do it as it does not have to be a POST request containing auth related stuff like client-id's) we can choose between using a workaround like described above OR expose our tenant and client-id's to everybody within our Javascript code (where the POST requests would then be issued from), we do not want to expose such information to the public and therefore we went with the redirect-proxy approach.
The ideal approach (IMHO) would be if we can create an endpoint which is called through AJAX and handles the logic & request-making by receiving simple commands passed trough GET params or other means. The POST/PUT/DELETE requests would then be made from within that endpoint by means of using the http.client...
