API errors & bugs
https://api.guildwars2.com/v1/skin_details.json?skin_id=2388
{"error":10,"product":71,"module":2,"line":314,"text":null}
source of skin_id: https://api.guildwars2.com/v1/item_details.json?item_id=23009
https://api.guildwars2.com/v1/skin_details.json?skin_id=2388
{"error":10,"product":71,"module":2,"line":314,"text":null}
source of skin_id: https://api.guildwars2.com/v1/item_details.json?item_id=23009
There are quite a few skin IDs listed on items that aren’t in the skins API. They also don’t appear in the wardrobe.
In item_detail.json, there are a lot of upgrade_components with:
“upgrade_component”:{"type":“Default”,
Jewels (gemstone are type “gem”), Infusions, PvP Rune and PvP Sigils, are all type “Default”.
Is this an error? If not, is possible to better differentiate upgrade components?
I have found that the following image are 16×16 instead of 32×32 like the others:
item_id:24695 Major Rune of the Flock
https://render.guildwars2.com/file/2BA523C17A3BE0D6D2EC773361746A6FE3282E23/222500.png
https://render.guildwars2.com/file/2BA523C17A3BE0D6D2EC773361746A6FE3282E23/222500.jpg
item_id:24766 Minor Rune of Dwayna
https://render.guildwars2.com/file/BC7E4DD2B7717AD7054CAFE103C7BEAC55C8142B/222502.png
https://render.guildwars2.com/file/BC7E4DD2B7717AD7054CAFE103C7BEAC55C8142B/222502.jpg
The World API appears to be returning empty arrays for all supported languages, and looks like it might have been doing that for the last few days.
Example: https://api.guildwars2.com/v1/world_names.json?lang=en
The World API appears to be returning empty arrays for all supported languages, and looks like it might have been doing that for the last few days.
Example: https://api.guildwars2.com/v1/world_names.json?lang=en
Any word on this??? My application has been hurting for days….
Jade Quarry Commander
The World API appears to be returning empty arrays for all supported languages, and looks like it might have been doing that for the last few days.
Example: https://api.guildwars2.com/v1/world_names.json?lang=en
Any word on this??? My application has been hurting for days….
Stefan posted that they are aware of the issue and working on it here: https://forum-en.gw2archive.eu/forum/community/api/Looks-like-some-of-the-API-is-broken/first#post3999815
The event APIs seem to be missing entries for the Triple Trouble wurm events. Bug?
The APIs are missing OAuth support.
The World API appears to be returning empty arrays for all supported languages, and looks like it might have been doing that for the last few days.
Example: https://api.guildwars2.com/v1/world_names.json?lang=en
It’s been over a week since this API first went down. Any word on it???
Right here: https://forum-en.gw2archive.eu/forum/community/api/Looks-like-some-of-the-API-is-broken/3999815 – no ETA but fixes provided.
The APIs are missing OAuth support.
Recipe 9642 (link)
This recipe does not specify a single crafting discipline. Also, its output item ID (66200) does not exist in the item details API.
Further research indicates that this recipe produces an “Unidentified Orange Dye”.
Chat link codes:
- [&CqolAAA=]
- [&AgGYAgEA]
If this recipe clearly exists in the game, why does the API behave like this?
(edited by StevenL.3761)
The same goes for recipe 9638
As I posted in separate thread. Affected recipes are 9637 – 9660
Missing skin with id=1053. Related item is “item_id=39532”
https://api.guildwars2.com/v1/skin_details.json?skin_id=1053
returns:
{"error": 10, “product” : 71, “module”: 2, “line”: 314, “text”: null}
Edit:
Like Dr Ishmael said, there are a lot more skins missing. So far I have a list of 100 skin_ids that don’t have a json-string for the details:
3689 3265 3245 3244 3242 3241 3192 3190 3188 3187 3186 2809 2775 2743 2434 2399 2398 2396 2395 2392 2391 2389 2388 2387 2385 2384 2339 2329 2327 2326 2325 2318 2009 1763 1570 1249 1248 1247 1233 1218 1217 1215 1214 1213 1212 1211 1194 1193 1183 1182 1181 1180 1179 1178 1177 1176 1175 1174 1173 1171 1168 1167 1166 1165 1164 1161 1159 1158 1150 1149 1148 1147 1142 1133 1118 1117 1115 1114 1112 1110 1109 1108 1088 1083 1080 1078 1076 1073 1070 1068 1067 1065 1063 1061 1059 1058 1056 1055 1054 1053
(edited by Leylin.3901)
The APIs are missing OAuth support.
The APIs are missing OAuth support.
Will be done before Half Life 3 comes out!
BTT: http://api.guildwars2.com/v1/guild_details.json?guild_id=4FB641DA-71BB-E311-8D3D-AC162DC0A8ED
{
error: 3019,
product: 1004,
module: 2,
line: 2646,
text: null
}
This guild id pops up frequently in current wvw matches.
Bugs in /v2
- duplicate identifiers in bulk requests are allowed
* /v2/quaggans?ids=404,404,404,404,… - As a result, X-Result-Count can be greater than X-Result-Total
* ids=404,404,404,404,404,404,404,404,404,404,404,404,404,404,404,404,404,aloha,404,404,404,404,404,404,404,404,404,404,404,404,404,404,404,404,404,404
* X-Result-Count:36
* X-Result-Total:35
Bugs in /v2
- duplicate identifiers in bulk requests are allowed
* /v2/quaggans?ids=404,404,404,404,…
I wouldn’t consider this as a bug, not even an error. For example imagine some SQL:
SELECT * FROM table WHERE id IN(404,404,404,404)
This is totally valid and would return exactly one line.
(edited by smiley.1438)
It’s a bug because it is (indirectly) violating a design constraint. The constraint would be:
X-Result-Count <= X-Result-Total
I suppose they could just decide to increase the Total by 1 for each duplicate identifier, but I’d rather get an error.
… is totally valid and would return exactly one line.
That’s not what is happening though. The output contains duplicate objects.
(edited by StevenL.3761)
Look again at what i’ve quoted.
I don’t agree that passing duplicate identifiers is a bug. (in fact: it’s compensating bad programming on the client side)
I agree that the output is bugged.
However, it’s still too early to report/discuss v2 bugs. The v2 API is still in the works and not officially released yet.
(edited by smiley.1438)
You suggest that I should be allowed to request ?ids=404,404,404 but get only a single response object even though my program is expecting three objects? Nope, nope, nope, so much nope.
You suggest that I should be allowed to request ?ids=404,404,404 but get only a single response object even though my program is expecting three objects? Nope, nope, nope, so much nope.
So does SQL. If you really think the API should act in a way YOUR program expects it to work, you’re wrong.
So tell me why:
- should the API return an error
- should it return the SAME object more than once
when you sent duplicate identifiers? How would your program handle the result of a SQL “…WHERE … IN(…) …”?
(edited by smiley.1438)
If you really think the API should act in a way YOUR program expects it to work, you’re wrong.
Exactly my point… it should crash with an error.
{"text":"request contains duplicate identifiers."}
My program doesn’t expect the API to return an error, because I’m not violating any protocols. But instead of leaving my program in an invalid state ( count < expected ), I now have an error code that I can use to throw an exception.
(edited by StevenL.3761)
Honestly, i don’t care how YOUR program works. If it’s unable to handle the response to what it asked for, you should rewrite it. Keep that SQL in mind, this is actually what to expect as response when duplicate identifiers are sent.
We’ve already established that they are not using that particular SQL construct. Otherwise we wouldn’t be getting duplicate objects in the response content.
We’ve already established that they are not using that particular SQL construct. Otherwise we wouldn’t be getting duplicate objects in the response content.
And we agreed that the output is incorrect. This doesn’t invalidate my previous point:
Keep that SQL in mind, this is actually what to expect as response when duplicate identifiers are sent.
SELECT * FROM table WHERE id IN(404,404,404,404)
This is totally valid and would return exactly one line.
(edited by smiley.1438)
The output is incorrect, but returning output other than what is requested is also incorrect. I don’t expect a fish when I ask for a basket of eggs.
You’re right about it being a client side error. You’re wrong about allowing the client to continue when it does that.
(edited by StevenL.3761)
So you really expect the API to do something like that:
foreach($identifiers as $identifier){
SELECT * FROM table WHERE id = $identifier
}
A programmer who writes API backend code like that should be hung by the balls.
(edited by smiley.1438)
I don’t know if that’s how they implemented it, but at least that’s how it behaves right now. So I’m using that as the specification.
They may have written it like this:
SELECT * FROM quaggans WHERE ID = "404"
UNION ALL
SELECT * FROM quaggans WHERE ID = "404"
UNION ALL
SELECT * FROM quaggans WHERE ID = "404"
UNION ALL
...
(edited by StevenL.3761)
I think it’s a bug you’re talking about unreleased (if it ever gonna be) API’s
As far as we know the quagans where perhaps still disabled and they just forget to lock them up again.
Processing and returning the same result more than once is just stupid. Assigning the result rows to the requested identifiers can be easily handled on the client side.
The output is incorrect, but returning output other than what is requested is also incorrect. I don’t expect a fish when I ask for a basket of eggs.
You get what you’ve asked for. You wanted $identifier X, you get the data for it. Once. Even if you send it a thousand times, the data will still stay the same.
As far as we know the quagans where perhaps still disabled and they just forget to lock them up again.
Who is “we” and where do you know from?
(edited by smiley.1438)
this page will show that all the v2 api’s are disabled but not the quagans.
i even wrote a little app thats running to tell me when its finaly freaking active.
but i gave up since we never get an actuall update anywhere.
just now and then i check up on this part of the forum but i realy dont know why i still bother.
As far as we know the quagans where perhaps still disabled and they just forget to lock them up again.
Well, no. The /v2 page that was posted on twitter didn’t even have an entry for /v2/quaggans. They added quaggans to the list a couple of weeks later, unlocked, presumably to help you and me get acquainted with the new syntax. I don’t know why they never made a public announcement, but that could mean anything (including nothing).
(edited by StevenL.3761)
You get what you’ve asked for. You wanted $identifier X, you get the data for it. Once. Even if you send it a thousand times, the data will still stay the same.
I didn’t mean it like that. We’re starting to mix up different ideas.
How it is right now
- I ask for 40 yellow easter eggs
- I receive 40 yellow easter eggs
- The receipt says that 35 eggs are in stock
- The receipt says that I received 40 of 35 eggs
How you say it should be
- I ask for 40 yellow easter eggs
- I receive 1 yellow easter egg
- The receipt says that 35 eggs are in stock
- The receipt says I received 1 of 35 eggs
How it should be
- I ask for 40 yellow eggs
- The cashier explains to me that there is only 1 yellow egg
You get what you’ve asked for. You wanted $identifier X, you get the data for it. Once. Even if you send it a thousand times, the data will still stay the same.
I didn’t mean it like that. We’re starting to mix up different ideas.
How it is right now
- I ask for 40 yellow easter eggs
- I receive 40 yellow easter eggs
- The receipt says that 35 eggs are in stock
- The receipt says that I received 40 of 35 eggs
How you say it should be
- I ask for 40 yellow easter eggs
- I receive 1 yellow easter egg
- The receipt says that 35 eggs are in stock
- The receipt says I received 1 of 35 eggs
How it should be
- I ask for 40 yellow eggs
- The cashier explains to me that there is only 1 yellow egg
Seriously? You compare data to physical eggs? You should better work in a supermarket when you think that way.
You asked for 40x the same string of text. You get it once instead because i don’t want to write it down 40 times as it would be a waste of my resources, but you are free to copy it as many times you want.
(edited by smiley.1438)
Dude, why are you so mean? My analogy is not about comparing data to physical objects. It is about comparing public services to public services.
You don’t even realize that what you’re doing is almost exactly what I want the API to do.
HTTP Error 400 Bad request
{
"text" : "You asked for 40x the same string of text. You *can* get it once instead if you simplify your request."
}
Forcing me to try again instead of giving me something I’m not asking.
(edited by StevenL.3761)
Dude, why are you so mean? My analogy is not about comparing data to physical objects. It is about comparing public services to public services.
Even comparing apples to tomatoes would make more sense.
HTTP Error 400 Bad request { "text" : "You asked for 40x the same string of text. You *can* get it once instead if you simplify your request." }
Forcing me to try again instead of giving me something I’m not asking.
Why would you force someone to change the request even if you could deliver what has been requested?
Anyway, off-topic, request for split into a new topic if there’s still reason to discuss.
(edited by smiley.1438)
Even comparing apples to tomatoes would make more sense.
As you wish
http://www.diffchecker.com/c8dpl9j2
Why would you force someone to change the request even if you could deliver what has been requested?
For the purpose of only ever returning exactly what has been requested. That, or an error. Do you really have no clue why that might be important?
(edited by StevenL.3761)
Do you really have no clue why that might be important?
It isn’t. You make it up.
You get it once instead because i don’t want to write it down 40 times as it would be a waste of my resources, but you are free to copy it as many times you want.
(edited by smiley.1438)
I swear I’m not making this up.
Assuming that you have an error handler that sits somewhere between the code that makes the request and the code that handles the response. This error handler is the same for all services, because the error response is the same for all services. It doesn’t matter which service gives you the finger, because your error handler has got your back.
On the other hand, things gets complicated a lot faster if you have to verify that the response is what you’d expect for each and every request that you make. It is not unlikely that you’d end up writing custom code for each endpoint.
Furthermore, if you know that you will only get what you asked for, you can make other assumptions about your code such as how big an array has to be to fit all elements inside. I know that this doesn’t apply to PHP, but it does in C# and other languages.
You can do this:
You get it once
Or you can do this:
i don’t want to write it down 40 times
But you cannot combine these two statements in a single response object.
Ok, programming 101:
You have a list of numbers which you want to send to an API and get the corresponding data for each of them. The API accepts duplicates of the numbers for convinience but returns just one result for each unique. Now back in your program you loop through your list of numbers and assign the data you recieved to each of them. This is possible. In (nearly) any language. Profit.
Custom code alert.
I can do the same thing through reflection if the response did have the duplicate entries. But the duplicates break the X-Result headers, so we can’t have duplicates. So we can’t have reflection. Unless we get errors.
The API accepts duplicates of the numbers for convinience
That’s funny, I find it very *in*convenient.
(edited by StevenL.3761)
(in fact: it’s compensating bad programming on the client side)
It’s not bad code that lets me send duplicate identifiers.
It is the absence of code that guards against it that lets me send duplicate identifiers.
In which universe do you only have to check preconditions on the client side but not on the server side?
In which universe do you only have to check preconditions on the client side but not on the server side?
In one where redundant data is uncool.