As soon as the word got out that I managed to use Online Management API to create backups in Azure, Marius Agur Pedersen reached out to me about the support case with Microsoft that he had in the limbo for a number of weeks.
Basically, Marius was able to retrieve instances but any attempt to backup was failing with the error 500. My code, however, was working just fine. After couple hours of joint efforts (plus whopping 50+ days for Marius), success! Long story short, accept-language header is a must have for some operations but not the others.
After a bit more digging, it turned out to be a well-hidden case of RTFM. As documented in getting started (highlight mine):
The Online Management API has following standard request and response headers.
|Accept-Language||“en,” “es,” etc.||Specifies the preferred language for the response. Services are not required to support this, but if a service supports localization it MUST do so through the Accept-Language header.|
|Authorization||String||Authorization header for the request. See Authenticate to use the Online Management API|
All problems went away after this line of code:
request.Headers.AcceptLanguage .Add(new StringWithQualityHeaderValue("en-US"));
(While you’re at it, check out his admin api project. It’s early days but looks promising).
In Marius defence:
- How do we tell if a service supports localization? What is so locale-specific about the backup, for example?!
- Is that such a big deal to assume the language of the instance or imply en-US and issue a warning but without failing the entire operation?
- Would it kill to return something better than a non-descriptive error 500?
The reason it worked for me was that I used a wrapper class that automatically inserted that header. To confusing everyone even further, for quick testing I was using Postman extension while Marius was using the desktop version. Former would add the language header automatically just for giggles.
Current advice? Always add accept-language header – no harm done if it’s not needed.