Sulsay [2173590]

I like the idea, I'll implement this in AWH! Not sure when quite yet, but I will. The fake reports problem can be solved by giving each client (read: app) a secret to include in the posts. I wouldn't bother though until it becomes an issue, if ever. The post body of your write request looks off. For "items", you seem to expect an object with item_ids as keys, but you're using array syntax in your example. If up to me, I'd use an array where each entry is an object with keys item_id, quantity and cost. I also feel it makes more sense for your API to detect items that do belong in a country but aren't available at this time. That means clients won't need to include those items in their post body (with zero quantity), centralizing this logic in your API instead of requiring each app to re-invent that wheel. For the GET request; I think it'd be good to allow no filters at all - and return all item stocks from all countries in that case. You could significantly reduce the size of the response by only returning item_id, country, stock data + cost, instead of including all the item meta data if bandwidth is a concern.

Sulsay [2173590]

Mephiles The way TORN handles collections of items in the api shouldn't matter. Don't base your approach on how hard it is to write. Go for the best api, not the easiest. It's a long term initiative and public facing, so it makes sense to go with whatever describes the domain best. In this case, it's a "list of items". Using an object forces the IDs to be strings, which they aren't. They are integers, so using an object is semantically incorrect. Making items with zero stock optional in the post body is what I meant to say. With ArsonWarehouse I scan the table abroad and take all items, but ones that are out of stock are simply not included in the html, and therefor not posted. So, counting an item that's excluded from the post body as zero seems to be te most sensible thing to do on the side of YATA. Ofcourse, sending 0 has the same effect but again, should not be required. Kivou I think it's sensible to expect all apps to post the full stock table to your api. I say this to convince you to build that auto-zero assignment. I can't see why any app would benefit from making partial posts regarding stock data while everything is clearly there on a single page. At least, not if their goal is to provide transparency for all players. For the post data choice between array or object, I think we should approach the data from the domain point of view. It's a list of items, not a hash/dictionary (which also isn't primarily meant to iterate over). The GET request can be as simple as possible, yeah. Let consumers fetch their own item data if they want to. I feel it doesn't make much sense to include it all in the an endpoint that is meant to get the foreign stock. EDIT: Oh yeah, I wanted to suggest sticking with one way of doing things. Don't support multiple formats, such as for the country. Either accept an integer representing a country or an exact string. It provides clarity for api consumers and prevents possible confusion. The client feeding the database will know how to properly transform data before POSTing it. Or, well, they should :-)

Sulsay [2173590]

Mephiles The way TORN handles collections of items in the api shouldn't matter. Don't base your approach on how hard it is to write. Go for the best api, not the easiest. It's a long term initiative and public facing, so it makes sense to go with whatever describes the domain best. In this case, it's a "list of items". Using an object forces the IDs to be strings, which they aren't. They are integers, so using an object is semantically incorrect. Making items with zero stock optional in the post body is what I meant to say. With ArsonWarehouse I scan the table abroad and take all items, but ones that are out of stock are simply not included in the html, and therefor not posted. So, counting an item that's excluded from the post body as zero seems to be te most sensible thing to do on the side of YATA. Ofcourse, sending 0 has the same effect but again, should not be required. Kivou I think it's sensible to expect all apps to post the full stock table to your api. I say this to convince you to build that auto-zero assignment. I can't see why any app would benefit from making partial posts regarding stock data while everything is clearly there on a single page. At least, not if their goal is to provide transparency for all players. For the post data choice between array or object, I think we should approach the data from the domain point of view. It's a list of items, not a hash/dictionary (which also isn't primarily meant to iterate over). The GET request can be as simple as possible, yeah. Let consumers fetch their own item data if they want to. I feel it doesn't make much sense to include it all in the an endpoint that is meant to get the foreign stock. EDIT: Oh yeah, I wanted to suggest sticking with one way of doing things. Don't support multiple formats, such as for the country. Either accept an integer representing a country or an exact string. It provides clarity for api consumers and prevents possible confusion. The client feeding the database will know how to properly transform data before POSTing it. Or, well, they should :-)

Sulsay [2173590]

Mephiles The way TORN handles collections of items in the api shouldn't matter. Don't base your approach on how hard it is to write. Go for the best api, not the easiest. It's a long term initiative and public facing, so it makes sense to go with whatever describes the domain best. In this case, it's a "list of items". Using an object forces the IDs to be strings, which they aren't. They are integers, so using an object is semantically incorrect. Making items with zero stock optional in the post body is what I meant to say. With ArsonWarehouse I scan the table abroad and take all items, but ones that are out of stock are simply not included in the html, and therefor not posted. So, counting an item that's excluded from the post body as zero seems to be te most sensible thing to do on the side of YATA. Ofcourse, sending 0 has the same effect but again, should not be required. Kivou I think it's sensible to expect all apps to post the full stock table to your api. I say this to convince you to build that auto-zero assignment. I can't see why any app would benefit from making partial posts regarding stock data while everything is clearly there on a single page. At least, not if their goal is to provide transparency for all players. For the post data choice between array or object, I think we should approach the data from the domain point of view. It's a list of items, not a hash/dictionary (which also isn't primarily meant to iterate over). The GET request can be as simple as possible, yeah. Let consumers fetch their own item data if they want to. I feel it doesn't make much sense to include it all in the an endpoint that is meant to get the foreign stock. EDIT: Oh yeah, I wanted to suggest sticking with one way of doing things. Don't support multiple formats, such as for the country. Either accept an integer representing a country or an exact string. It provides clarity for api consumers and prevents possible confusion. The client feeding the database will know how to properly transform data before POSTing it. Or, well, they should :-)

Mephiles [2087524]

I understand what you mean by "[color=#333333][size=12][i]It's a long term initiative and public facing, so it makes sense to go with whatever describes the domain best. In this case, it's a "list of items". Using an object forces the IDs to be strings, which they aren't. They are integers, so using an object is semantically incorrect.[/i][/size][/color]" But my reasoning on why we should go with object rather than an array is because Torn is using it already. I think it matters because it would be better to match Torn's format. Like you said "[color=#333333][size=12][i]Either accept an integer representing a country or an exact string. It provides clarity for api consumers and prevents possible confusion[/i]". Matching Torn's format also provides clarity.[/size][/color]

GreekPoser [2527893]

Thanks for the hard work. I'm coming from the YATA site. As I understand, we need to use the script to share data when we are abroad right? I will share it with my faction mates