The workaround here is to click on the link provide your own token instead of using your credentials to sign in.
To generate a simple access_token using the client_credentials flow one alternative is using the Rested extension for Google Chrome or Mozilla Firefox:
Well, it seems I can’t GET anything anymore as well. 
I’m a complete noob in APIs for my part.
So when accessing one of the legacy API of this page :
https://develop.battle.net/documentation/starcraft-2/community-apis
Am I supposed to click on provide my own access token, and then paste this ?
function getSslPage($url, $userAgent)
{
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_USERAGENT, $userAgent);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_REFERER, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_POSTFIELDS, []);
$result = curl_exec($ch);
curl_close($ch);
return json_decode($result, true);
}
$userAgent = 'Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0';
$url = "https://eu.battle.net/oauth/token?client_id=XY&client_secret=XY&redirect_uri=XY&scope=wow.profile&grant_type=authorization_code&code=$authcode";
$data = getSslPage($url, $userAgent);
While filling the first XY with my client ID, the second one with my client secret, and the third one with :
https://develop.battle.net/documentation/starcraft-2/community-apis
Unfortunately for profile related APIs it is a little more complicated because it requires a valid token generated with the authorization code flow.
This means you need to make all the requests on this documentation
Ok.
Then I hope they will fix this quickly 'cause I’m afraid I don’t have the time for blind trial and error through the documentation. 
Thanks for your answer regardless.
I guess you can use Postman to get a valid token:
Thanks, I’ll consider it if the wait for the fix becomes too long. At least I’ve got an alternative in that case. 
I just want to thank the API devs for implementing another unannounced change. I was getting bored with everything working all the time.
I was able to fix my code thanks to the information in this thread. For the record: I only saw “400 Bad Request”, I never saw anything about GET being bad all of a sudden. The fix was as simple as changing GET to POST in my C# code, but digging to the right location took a while …
I agree, the communication of this kind of things sure could use some improvement.
Yeah, that turned out to be a mistake on my end. After good night sleep I found out my data fetching implementation was faulty (sending GET requests even when I thought it would POST) and managed to fix it. Thanks!
Fair warning, providing your own access_token doesnt necessarily work either.
E.g., making a request to this endpoint:
/profile/user/wow?namespace=profile-us&locale=en_US&access_token=${accessToken}
with a valid access token results in a 404. Attempting the same from Blizzard’s documentation (by including an access token) also results in a 404.
*Edit: Note, the access token for this endpoint acquired through the authorization code flow.
I’ve seen a lot of 404 errors recently, they happen often (but not exclusively) for very recent profiles (possibly depending on some privacy settings as well). Interestingly enough when I’ve got a 0404 on an EU profile with an EU region parameter, going for the exact same request with an US region gets an errorless but empty response .
Anyway, if that’s a 0404 just going for another profile ID should get rid of it. It’s different from the 0401 or “GET method not allowed” we get for every request since half a day I think. 
So if I understand you well, until the devs change the GET button to a POST one in their pages, the GUIs are unusable ? 
https://develop.battle.net/documentation/starcraft-2/community-apis
Either this or Blizzard devs bringing back the ability to GET OAuth access tokens, whichever comes first. 
seems to be fixed, at least for me
YES !
The GUI works again on my side too ! 
Greetings all,
First, we would like to apologize for the disruption and confusion that some API consumers have experienced over the last 24 hours.
We are able to confirm that there was indeed a change deployed which altered the behavior of the OAuth APIs for the /oauth/token endpoint, which removed support for HTTP GET requests. This change was applied with the best intentions to ensure the best security practices are followed for the Blizzard OAuth APIs, however, we realize that this also negitively impacted a number of consumers. We failed to communicate this change ahead of time, and for that we deeply apologize.
This change hase since been reverted, and requests to /oauth/token using HTTP GET should continue to work as they previously did. Our intention is to once again disable HTTP GET requests to the /oauth/token endpoint at a later date, and we ask consumers to please account for this in your integrations by migrating to using HTTP POST. Please keep an eye out for further communication at a later date regarding migrating.
We would like to extend our thanks to everyone who reported issues, and to everyone who assisted others with debugging & troubleshooting efforts here on the forums and through other channels.
Thank you for all of your feedback, reports, and collaboration.
If it was possible, please then consider changing the GET requests mode from the GUIs (such as this ones) simultaneously, as otherwise it requires third party programs to send the oauth token and knowledge of command lines which will leave some of us wondering for a while.
And most particularly Schiller, who seems always ready to provide some advice. 
For what it’s worth, speaking for myself here, I totally get why the change was made. IIRC the spec always said “use POST” and your change did not deviate from that spec, you simply stopped supporting an unofficial alternative method. If we had all been following the spec, we wouldn’t notice you made any change at all. On my own projects, I had some code to fix, but at work I followed the spec 100% and didn’t have any interruption in service. So, technically, the change should’ve been harmless, and indeed been an improvement since the method change could make things more secure in regards to request logs, etc.
However, lots of folks were using GET requests, as evidenced by this thread, as well as your own documentation examples. It would have been nice if you noticed this in your logs, ideally before, but especially after, this change. I think we could’ve supported this change with a minimum of moaning about it if we were given advance notice.
As an API consumer, here’s my feedback for this incident.
Kudos:
Opportunities for improvement:
Sounds good. I think a lot of us are already ready for it, after this incident. 
I think he’s our only forum MVP who I really believe deserves the title.
Hi, just to let you know:
To get my access-token for the Authentication Code Flow in Postman, this configuration did not work to me, I had to change the “Client Authentication” option to “Send client credentials in body”, instead of “Send as Basic Auth header”.
Thank you anyway because this screenshot helped me a lot.