Интерфейс приложений API Phrase TMS

ИНТЕРФЕЙС ПРИЛОЖЕНИЙ API (TMS)

Контент автоматически переведен с английского языка с помощью Phrase Language AI.

Доступен набор интерфейс приложений API<1> вызовов, которые позволяют выполнять следующее:

  • Интеграция Phrase и любого стороннего программного обеспечения (Инструменты управления переводом, CMS и т. д.)

  • Разработка рабочего места переводчика. CAT Editor построен на основе общедоступных интерфейсов приложений API.

  • Создание совершенно нового Инструменты или услуга с использованием Phrase в его серверной части.

Базовый рабочий процесс

Процедуры и рабочий процесс должны быть понятны перед использованием интерфейсов приложений API. Рекомендуется ознакомиться с процедурой в Phrase перед реализацией соответствующего интерфейса приложений API.

Базовый рабочий процесс:

  1. Создать память переводов (TM) TM, базу терминов (TB) TB и, при необходимости, добавить машинный перевод система.

  2. Создать проект с прикрепленной памятью переводов (TM)/базой терминов (TB)/системой машинного перевода (если необходимо).

  3. Сохранить проект как шаблон проекта и повторно использовать его, чтобы создать новый проект перевода.

  4. Загрузить файл для перевода в проект (создать задание).

  5. Затем вы можете анализировать, Предварительно перевести<2> или назначить задание лингвисту.

Асинхронные интерфейсы приложений API

Асинхронным интерфейсам приложений API всегда следует отдавать предпочтение перед их синхронными аналогами. При вызове синхронных интерфейсов приложений API существует вероятность получения ответов об истечении времени ожидания при обработке больших пакетов файлов или даже одного большого файла. Синхронные интерфейсы приложений API следует использовать только для небольших файлов и интеграции небольшого масштаба.

Опрос

После вызова асинхронного интерфейс приложений API мгновенно получается ответ, включающий идентификатор запроса. Использовать этот идентификатор для проверки статус запроса путем вызова getAsyncRequest и проверки поля asyncResponse. Такой подход с опросом может привести к ряду вызовов getAsyncRequest перед получением asyncResponse, который не является пустым.

Обратные вызовы

В качестве ответа на недостатки подхода с опросом для асинхронных запросов поддерживается использование обратных вызовов во всех асинхронных интерфейс приложений API. При вызове асинхронного запроса укажите URL-адрес (в параметре callbackUrl), который запрашивается после того, как работа, инициированная асинхронным запросом, будет Завершить.

Обратные вызовы запрашиваются через вызовы HTTP POST, а данные передаются в теле, закодированном в формате JSON. Объект JSON всегда содержит:

  • Информация об асинхронном запросе (такая же, как при вызове getAsyncRequest).

  • Подробная информация о результате действия, такая как полный анализ или детали задание.

{
   "asyncRequest": {
       ...
  }
 "analyse": {   
   ...
  }
}

Если URL-адрес обратного вызова недоступен, запрос повторяется через 2, 4, 8, 16 и 30 минут, пока не произойдет 10 неудачных попыток.

URL-адрес обратного вызова должен отвечать кодом HTTP статус 200 OK, чтобы считаться успешным.

Была ли эта статья полезной?

Sorry about that! In what way was it not helpful?

The article didn’t address my problem.
I couldn’t understand the article.
The feature doesn’t do what I need.
Other reason.

Note that feedback is provided anonymously so we aren't able to reply to questions.
If you'd like to ask a question, submit a request to our Support team.
Thank you for your feedback.