Я работаю над созданием веб-сервиса RESTful. Я прочитал о принципах использования HTTP для каждого механизма, насколько это возможно, и большую часть времени, например, при извлечении ресурсов, он работает довольно хорошо.

Но когда мне нужно ПОСТАВИТЬ новую запись некоторого вида, в интересах ясности и надежности, независимо от того, что может сделать клиент, я хочу предложить конкретные ошибки проверки, при которых новая запись могла потерпеть неудачу. Кроме того, существуют конкретные ошибки, когда, скажем, данные для создания нового пользователя являются абсолютно действительными, но можно использовать псевдоним или адрес электронной почты. Просто возвращаясь409 Conflict не достаточно подробно, какой из псевдоним или адрес электронной почты был взят.

Так что обойти это не ракетостроение: задокументировать кучу конкретных кодов ошибок и вернуть объект с ошибками:

{ errors: [4, 8, 42] }

Это означает, что в случае неудачных запросов я не возвращаю ресурс или его ключ, как это может ожидать философия REST. Точно так же, когда я возвращаю много ресурсов, я должен каким-то образом разместить их в массиве.

Итак, мой вопрос: буду ли я по-прежнему предоставлять хорошо себя зарекомендовавший веб-сервис RESTful, если я стандартизирую конверт для использования для каждого запроса, такой, что, например, всегда есть такой объект, как{ errors, isSuccessful, content }?

Ранее я создавал веб-сервисы в стиле RPC, которые использовали это, но я не хочу делать что-то, что «почти ОТДЫХАЕТ». Если и будет какой-то смысл быть ОТДЫХАМ, я бы хотел быть как можно лучше.

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