Доступен набор вызовов интерфейса приложений API, которые позволяют выполнять следующее:
-
Интеграция Phrase и любого стороннего программного обеспечения (Инструменты управления переводом, системы управления контентом и т. д.)
-
Разработка рабочего места переводчика. CAT Editor построен на основе общедоступных интерфейсов приложений API.
-
Создание совершенно нового инструмента или услуги с использованием Phrase в качестве бэкенда.
Базовый рабочий процесс
Перед использованием интерфейсов приложений API необходимо понять процедуры и рабочий процесс. Рекомендуется ознакомиться с процедурой в Phrase перед реализацией соответствующего интерфейса приложений API.
Базовый рабочий процесс выглядит так:
-
Создать память переводов (TM), базу терминов (TB) и, при необходимости, добавить систему машинного перевода.
-
Создать проект с прикрепленной памятью переводов (TM)/базой терминов (TB)/системой машинного перевода (если нужно).
-
Сохранить проект как шаблон проекта и использовать его повторно, чтобы создать новый проект перевода.
-
Загрузить файл для перевода в проект (создать задание).
-
Затем вы можете анализировать, предварительно перевести<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, чтобы считаться успешным.