Здравствуйте, Буравчик, Вы писали:

Б>Какие HTTP status code используются в ваших API?
Б>200, 401, 403, 404 и т.п.
Используем все.
200 (OK) — все OK, в теле ответа будут данные
201 (Created) — все ОК, новая сущность создана. Обычно в ответ на POST, в хидере Location — адрес новой сущности. В теле ответа могут быть данные.
202 (Accepted) — все ОК, мы твой запрос приняли, обработаем позже (e.g. положили в очередь). В теле ответа могут быть данные.
204 (No Content) — все ОК, мы твой запрос обработали, но контент вернуть не можем (обычно в ответе на DELETE)
308 (Permanent Redirect) — мы тут немного поменяли схему роутов, иди в другое место
400 (Bad Request) — с входящим запросом что-то не так (e.g. не прошла валидация, не хватает данных, неправильный формат и т.п.)
401 (Unauthorized) — мы не знаем, кто ты такой, иди авторизуйся
403 (Forbidden) — авторизовался? молодец! Но прав на доступ конкретно к этому ресурсу у тебя все равно не хватает
404 (Not Found) — ресурс не найден
409 (Conflict) — твоя локальная копия данных устарела (обычно для реализации оптимистичной блокировки в ответ на POST/PUT/PATCH)
429 (Too Many Requests) — если есть реализуется какой-то вариант rate-limiting'a
500 (Internal Server Error) — упс, мы где-то облажались. Уже работаем над этим.

Б>Передаете ли дополнительную информацию об ошибках? Какую?
Б>Код ошибки, текстовое сообщение, на каком языке (русский, английский), дополнительные параметры?
Да. Сама модель ошибки в теле запроса, e.g.

{
  "http_code": 403,          // Дублируем тут, для удобства клиента
  "code": "AccountBlocked",   // Код ошибоки.
  "message": "The account 'xxx' is blocked",  // На языке запроса (Accept-хидер), по умолчанию - английский
  "validation_errors": [
     { "field1": "error text1" },
     { "field2": "error text2" }
  ]
}

Б>Кодируете ошибки, как? Единая нумерация для всего API, или свои ошибки для каждого endpoint?
Обычные текстовые строки.
Есть какой-то глобальные набор ошибок (типа аккаунт заблокирован, требуется авторизация, входные данные некорректны и т.п.).
Иногда добавляются endpoint-специфичные.

Б>Используете какие-то правила для возвратов ошибок?
Б>Например, по аналогии с JSON-RPC, в котором наличие в ответе поля errors означает, что произошла ошибка при обработке запроса.
Есть JSON/XML-схема для кода ошибки.
Она описывается в SWAGGER-документации.

Б>Что возвращаете, если клиент запрашивает существующий ресурс, к которому запрещен доступ:
Б>404 или 403?
403

Б>В общем, научите как надо возвращать информацию об ошибках в API
Так, чтобы клиентам твоего API было удобно ей пользоваться