Возвращение закодированных данных формы, хотя это и не страшный подход, я никогда не видел в дикой природе. Лучше, я думаю, придерживаться более распространенных форматов. Большинство API-интерфейсов выбирают формат по умолчанию для отправки (обычно XML или JSON), когда ни один не указан в запросе.
Что касается ошибок, основным принципом REST является использование методов, которые HTTP уже предоставляет, поэтому сначала верните соответствующий код ошибки (в 400 с и 500 с ) вместе с сообщением об ошибке в теле ответа. .
Нет стандартного формата для тела сообщения об ошибке - это может быть так просто:
{ "error" : "Invalid articled ID" }
.. или более, например Flickr s:
{ "stat" : "fail",
"code" : "97",
"message" : "Missing signature"
}
.. и XML эквивалент:
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="fail">
<err code="97" msg="Missing signature" />
</rsp>
Очевидно, что разработчики, использующие ваш API, оценят более подробные сообщения об ошибках. Главным образом я думаю, что вам следует искать согласованность в вашем API - если у вас есть параметр с именем Message в одном месте, а параметр с именем message в другом месте.
Кроме того, я имел дело с действующим сторонним производственным API, который не только сделал вышеупомянутые faux pas , но и возвратил результаты в виде разделенных по конвейеру данных (|), заключенных в XML. Буквальные каналы в значениях были экранированы другой трубой (||). Я оставлю дальнейшие осложнения, которые мы обнаружили, на ваше воображение. Мораль, во всяком случае, состоит в том, чтобы использовать структуры и методы, к которым разработчики уже привыкли, и более того быть последовательными в выборе, который вы делаете.