JSON RPC 2.0 стандартные ответы

Question

В настоящее время я изучаю некоторые ответы JSON RPC 2.0 в своем коде. Тем не менее, я немного непонятно на что стандартные методы его использования:

1) Когда пользователь отправляет запрос с неправильными параметрами, я должен просто вернуть сообщение об ошибке по умолчанию дословного

{"jsonrpc": "2.0", "error": {"code": -32602, "message": " Invalid params"}, "id": "1"} 

Или может ли сообщение быть более конкретным, например:

{"jsonrpc": "2.0", "error": {"code": -32602, "message": " Invalid params: invalid username"}, "id": "1"} 

Или должны ли такие пользовательские сообщения иметь свой код ошибки?

2) Если пользователь скажет, что данные из базы данных и ответ «данные отсутствуют», так как в них мы не встречали ошибок, но ничего не возвращали, должны быть возвращены как JSON RPC error , или не должно быть больше ответов, указывающих данные не было найдено? Другими словами, согласуется ли в JSON RPC использование ошибок в качестве нормальных условий возврата, например, в Google Go, или это более похоже на «что-то действительно испорченное» паники?

Answer 1

1. В соответствии со спецификацией (http://www.jsonrpc.org/specification#error_object) необходимо использовать дополнительное свойство data для получения дополнительной информации об ошибке, поэтому в вашем случае ответ должен быть:

{"jsonrpc": "2.0", "error": {"code": -32602, "message": " Invalid params", "data":"invalid username"}, "id": "1"}

Вы может создавать ваши личные коды ошибок в диапазоне -32000 до -32099, но я сделал бы это только в случае необходимости, то есть, если ваше клиентское приложение не должно вести себя в этом случае («неверное имя пользователя»), отличное от того, y другой -32602 кейс.

2. Это зависит от вас. Это вопрос дизайна с более широким охватом, чем JSON-RCP. Вы можете найти несколько мнений на этом посту: when-to-throw-an-exception