We just ran into a situation I wanted to bring to your attention and hopefully help other developers in the future. Maybe a feature request or bug report.
Here’s the situation. We created a product feed calling a POST to the /product_feeds endpoint with the required data:
{"name":"Our Feed 20160914","url":"http:\/\/our.server.com\/files\/feeds\/example\/product_feed.tsv"}
The API replied:
{"errors":[{"code":"SERVICE_UNAVAILABLE","message":"Service unavailable due to request timeout; please try the request again later"}],"request":{"params":{}}}
A minute or two later, our job ran again, and we got another error trying to create the product feed:
{"errors":[{"code":"DUPLICATE_DETECTED","message":"A feed with the same url already exists"}],"request":{"params":{}}}
Sure enough, GET /product_feeds showed it existed.
We’ve since updated our code to check if a product feed exists calling the GET /product_feeds endpoint first, and parsing the results to see if a prior POST of ours actually succeeded. If so, we initiate upload, else try to create again.
My thoughts are that if Twitter Advertiser API replies with SERVICE_UNAVAILABLE we should be assured that our request was not honored. In this case it appears that it was, with a misleading false positive reply. It seems that in several cases we’ve received INTERNAL_ERROR from the API as well. In those cases, our objects were not created.
I’m a bit concerned now that I will need to go through all my code and check the GET endpoint and parse it before issuing POSTs to create objects, regardless of an error-like message from a prior POST.
Is this a bug, or the intended usage? I would think you’d prefer to minimize the number of required requests to implement a solution, and treat failure-type replies as transactional in nature, thereby reducing overhead on both ends. In other words, if you reply SERVICE_UNAVAILABLE to a post, in my opinion you should disregard it (delete it from your internal queues, if possible) since I naturally expected that it wasn’t created.
