It's pretty trivial to construct a URL programmatically on the API consumer's end using the other components of the returned response so I think it would even be acceptable to remove the profile field completely. Either way, its current response isn't really useable.
The Question (regarding BattleTag case-sensitivity)
I've noticed that this and several other endpoints that require a battletag parameter will accept a case-insensitive parameter value, but when returning the battletag in their response, they'll use whatever the provided value was (instead of returning a correctly cased value).
For example, /Player?region=1&battletag=player%231234 will return a battletag value of player#1234 when the correct casing is Player#1234.
I realize that this may actually be a feature and not a bug, but it used to be frustrating on the old HP website because the response URL would include the user-provided battletag. The user's profile URL was case-sensitive and so additional lookups were often necessary to find the correct casing of the battletag. The new website appears to treat the battletag as case insensitive in its URL structure.
With this change, I can't think of anywhere else the case-sensitivity makes a difference but it's possible that somewhere out there, something relies on the correct casing of a battletag.
I guess my main questions are...
Is returning an uncorrected battletag that matches the casing of the request parameter the intended functionality of the API?
If so, is it the intended functionality of the HP website to continue to accept case-insensitive battletag names in the URL?
I don't have a strong opinion about the answer, but as an endpoint consumer clarity on this allows for better planning around fringe cases.
Just have a comment about the /Player endpoint and a question about whether something is working as intended...
For reference, a current sample response of the /Player endpoint is:
{ "blizz_id": 67280, "battletag": "Player#1234", "region": "1", "account_level": 1734, "profile": "https://www.heroesprofile.com/Profile/?blizz_id=123456&battletag=Player®ion=1" }The Comment (regarding profile URL response)
The URL for the profile uses the pre-reworked HP website, when it should return a URL string representing:
https://www.heroesprofile.com/Player/<battletag_prehashsymbol>/<blizz_id>/<region>It's pretty trivial to construct a URL programmatically on the API consumer's end using the other components of the returned response so I think it would even be acceptable to remove the profile field completely. Either way, its current response isn't really useable.
The Question (regarding BattleTag case-sensitivity)
I've noticed that this and several other endpoints that require a battletag parameter will accept a case-insensitive parameter value, but when returning the battletag in their response, they'll use whatever the provided value was (instead of returning a correctly cased value).
For example, /Player?region=1&battletag=player%231234 will return a battletag value of player#1234 when the correct casing is Player#1234.
I realize that this may actually be a feature and not a bug, but it used to be frustrating on the old HP website because the response URL would include the user-provided battletag. The user's profile URL was case-sensitive and so additional lookups were often necessary to find the correct casing of the battletag. The new website appears to treat the battletag as case insensitive in its URL structure.
With this change, I can't think of anywhere else the case-sensitivity makes a difference but it's possible that somewhere out there, something relies on the correct casing of a battletag.
I guess my main questions are...
I don't have a strong opinion about the answer, but as an endpoint consumer clarity on this allows for better planning around fringe cases.