IMPORTANT MESSAGE: We are still experiencing some difficulties that will affect your ability work with the RWS AppStore. Our IT team is working to resolve this but for now you may not be able to download or upload apps through the RWS AppStore. We apologise for the inconvenience and will update the community when we have a resolution in place. In the meantime you can take advantage of the Private AppStore if you are using Trados Studio 2021 or 2022.

API Timeout

Hi,

What is the recommended, reasonable timeout for an application using the API?

Thanks in advance.

Fred

Parents
  • Hello Fred,

    60 seconds is considered a long time… most of our internal API calls have much shorter timeouts (5, 15 or 30 seconds), and we like to avoid hitting those limits! There are some infrastructure components (reverse proxy layer) which impose their own 60 second limit on pending requests – we rarely see this as a problem, and if it occurs it’s usually indicative of another behavior or problem (see concurrent requests spiel above). If we assume that the timeout applies to “time-to-first-byte”, and does not cover the time required to transfer a large response, then 30 seconds should be sufficient. The known slow methods (get all projects/at-status) do not scale indefinitely – and it’s when we see project lists of 10s of thousands of projects that the internal 60s limit can be reached – usually a different pattern is the answer… The same APIs are used to drive our web UI, and as you might imagine, 60s is an eternity to a user watching a “spinner”…
Reply
  • Hello Fred,

    60 seconds is considered a long time… most of our internal API calls have much shorter timeouts (5, 15 or 30 seconds), and we like to avoid hitting those limits! There are some infrastructure components (reverse proxy layer) which impose their own 60 second limit on pending requests – we rarely see this as a problem, and if it occurs it’s usually indicative of another behavior or problem (see concurrent requests spiel above). If we assume that the timeout applies to “time-to-first-byte”, and does not cover the time required to transfer a large response, then 30 seconds should be sufficient. The known slow methods (get all projects/at-status) do not scale indefinitely – and it’s when we see project lists of 10s of thousands of projects that the internal 60s limit can be reached – usually a different pattern is the answer… The same APIs are used to drive our web UI, and as you might imagine, 60s is an eternity to a user watching a “spinner”…
Children
No Data