We’re excited to announce the stable release of the newest version of Transifex API v3.
What is the impact for me?
Migrating from one version to another is never easy but the benefits you can get from using this new version are numerous. In our blog post here, you can find the history of Transifex APIs, the reasoning behind the decision to proceed with a new version, and its design philosophy.
What action do I need to take
If you rely on a script that makes requests using 2.0 and 2.5 resources, you may want to start migrating to API v3.
Sunset of Transifex API v2 and v2.5
API v2 and v2.5 are still operational. The sunset of these versions is expected by the end of 2022 (1 year after the deprecation period is announced). After that, all v2 and v2.5 API requests will begin to fail. We will provide additional information about the depreciation period soon.
How can I get more information?
More information about this new API version v3 can be found in our documentation guide here. As always, don’t hesitate to reach out to us, if you have questions while you’re upgrading. Feel free to reach out to us at support@transifex.com and we will be more than happy to assist you.
I was just looking at the API v3 and I wonder in which universe is it more usable (for the users) than API v2?
To download a translated file it takes at least 3 requests and it is required to check the “download” status. To use this in a batch job is very troublesome.
Please don’t deprecate API v2.
A migration will cause a lot of trouble.
Hello @michael-wirth ! Thank you for your feedback! To answer your question about how it can help users please refer to this blog post.
Furthermore, we believe that making all Upload/Download actions asynchronous helps you avoid delays and potential timeouts, while the retrieval from or the upload to the server takes place (imagine having to download a large file, for example).
If you need further assistance with the migration, please don’t hesitate to contact our support. We are here for you!
The Blog doesn’t show an example of how to download a resource file.
As far as I can see in V3 I need at least 3 requests and have to implement some polling in comparison to V2 where I can download a resource file with just one single request.
The new API is only an improvement if you measure the number of requests required to download a file.
Obviously, we believe in other categories.
I prefer the API with the least required number of requests and which can be used easily in a batch job.
I understand your point of view: you count the number of requests needed in APIv3 to download a file and you realize that now they are 3 instead of 1 in APIv2. The reason behind that is that the download action is asynchronous (whereas in APIv2 this was done synchronously).
Our product and engineering team took this decision while designing APIv3, having in mind all the benefits that asynchronous actions bring along, in regard to file I/O. Of course, the increased number of requests is a downside, but not enough by itself to outweigh the benefits.
We strongly believe that APIv3 is more robust, stable, and reliable (for all the reasons mentioned in the blog post). We can vouch for it since we already use it in our codebase and have seen the positive impact it has on user experience.
I would also like to point you to our Python SDK library, which can help you focus on the business logic for the in-house solution you are implementing: you can use just one function to download a resource file, instead of making all the required APIv3 requests. Even if Python is not the programming language you use, you can still get an idea of how to integrate APIv3 file download requests into your code (the library is open-sourced).
I really hope we have assisted you somehow in your efforts. We are certainly available if you have any questions with APIv3 or Python SDK.
