Перевод «service contract» в контексте описания модели REST для API

не надо переводить имена собственные. тем более акронимы. я бы ссылки на вики оставлял, но не более.

REST - да, я переводить не буду, слишком глупо выйдет. Хотя есть проблема в том, что документ получается как бы сказать не просто для внутреннего употребления, а довольно официальный.

Но вот контракты меня смущают. В принципе там никакой не контракт, это скорее просто справочник, справочное руководство и т.п. Но с оттенком некоей обязательности и потому контракт. Хз. Тяжело такие нюансы переводить.

если заниматься буквоедством, то API это сам интерфейс, а контракт - это документация к нему. Просто немного формализовали термин «документация» применительно к апям. Я бы сделал небольшой дисклеймер этого термина, а тексте бы использовал именно его.

Ну в принципе так и сделано. Вначале есть описание терминов, в том числе что такое сервисный контракт. Далее просто используются слова.

Формат протокола
Протокольное соглашение
Описъ командный
Тлумач реестровый

Протокольное соглашение

Хм, надо подумать. Хотя странновато звучит. Слово «протокольный» имеет намек на что-то ироничное.

Слово «протокольный» имеет намек на что-то ироничное.

Возможно потому что я дальше скатился в юмор? В моей культуре, например, у слова «протокол» нет никакого несерьёзного подтекста.

Гарантии обслуживания?

А какой смысл оно в английском несет? А то без контекста их базвордные слова никак не понять.

В моей культуре, например, у слова «протокол» нет никакого несерьёзного подтекста.

Ну например, выражение морда протокольная не встречал?

Контекст я описал.

Перечитал еще раз — ничего не понял. Ну ладно, описал так описал.

Для меня эта фраза звучит как прямиком из 80х.

Ну например, правило

API service contracts should include endpoint redirection feature.

С виду похоже на ТЗ.

Если переводить как «документация интерфейса» или «формат протокола», то получается что-то невнятное: надо, чтобы фича была описана или реализована? Я бы написал «Реализация протокола должна предоставлять функцию перенаправления».

Имхо, тут переводить «contract» как «контракт» или что-то подобное — ложный друг переводчика. На английском это значит «так работает», а на русском — «так написано».

С данного примера «contracts» мне похоже на «описание» или «работа» — Описание/Работа (contracts) API должно в себя включать функционал перенаправление ручек (endpoint).

надо, чтобы фича была описана или реализована?

Это правило проектирования фич. Что должно быть, чего нет и т.д.

То есть, может просто contract = протокол?

endpoints - это тоже тот еще баззворд. По факту - это точка с которой вызывается интерфейс чего-то.

Например, я редактирую это сообщение и endpoint здесь edit_comment в www.linux.org.ru/edit_comment

Не ну так звучит еще хуже сервисного контракта.

Думаю, что может сервисным протоколом просто заменить. Засада, что в тексте и слово protocol используется, причем в несколько другом контексте, а не как синоним.

Условия обслуживания.

Совсем не в тему. Начиная с того, что там именно сервис в компьютерном смысле. Для которого есть API

Техническое соглашение при работе с API

По смыслу переводите. а не по отдельным словам-терминам. Наиболее ходовые словосочетания «протокол взаимодействия чего-то с чем-то…» «описание протокола взаимодействия», «протокол процедуры конфигурации/конфигурирования/первоначальной настройки», «структура взаимодействия». Сначала подберите наиболее близкое русское слово, описывающее то, что вы хотите перевести, а потом на него навешивайте остальное. сверху вниз по мере детализации описания.

Это что-то вроде стандарта, в котором ключевые термины однажды определяются и потом строго используются в тексте.

Тем более. У переведенных терминов должна быть связность. Попробуйте написать сюда то, как уже вы перевели остальные

Например, только сейчас заметил, что слово служба использовал

«Representational State Transfer (REST)» содержит описание набора архитектурных принципов, с помощью которых данные могут передаваться через стандартизированный интерфейс, обычно HTTP. REST не содержит дополнительного уровня обмена сообщениями и сосредотачивается на правилах проектирования для создания сервисов без статических данных;

«Потребитель услуг (Service consumer) » означает роль среды выполнения, которую берет на себя программа, когда она обращается к сервису и вызывает его. Вернее, когда программа посылает сообщение в сервисную функцию, прописанную в сервисном контракте. Служба, после получения запроса, начинает обработку и может вернуть или не вернуть потребителю услуги соответствующее ответное сообщение;

это документ, в котором описывается как сервис для других программ раскрывает свои возможности в виде функций и ресурсов в рамках публикуемого

Описание протокола/интерфейса. Можно добавить слово «открытого/внешнего/публичного», будет по сути перевод аббревиатуры API. Можно «взаимодействие с сервисом», это апи+немного логики

есть какой-нибудь удачный перевод для сокращений REST

Если ты описываешь правила проектирования, то первым должно быть не допускать до проектирования людей, не знающих что это все значит.

Почему бы не оставить на таком уровне? Глубже переводить распространенные термины и аббревиатуры - это вы рискуете, что вас будет сложнее понять, чем до перевода )

Да наверное. Разве что контракт все-таки наверное буду заменять на протокол