REST/JSON/MVC Возвращаемые значения

Question

Не отличное название, но я ищу больше для некоторого руководства, искали совсем немного. Я создаю веб-приложение с картой MVC (но я думаю, что это более общий вопрос). Я пытаюсь сделать много просмотров, которые делают много вызовов стиля AJAX и говорят, что у меня есть сайт с пользователями, и они могут добавлять папки и файлы на свою страницу профиля. Таким образом, URL может быть, нравится:

/profile/{id}

У меня есть контроллер профиля, который возвращает представление с различной информацией. Я хотел бы, чтобы файлы и папки, перечисленные в профиле, были динамическими, поэтому я хочу заполнить его через вызовы AJAX. Я думал, я бы URL, как

/listFolders/{userId}

и

/listFiles/{folderId}

Разумно иметь эти URL-адреса возвращает объект JSON для этих двух URL, и даже не дают представление HTML (так как для браузера вид будет всего лишь страницей профиля)? Кроме того, что мне следует возвращать за ошибки, скажем, если пользователь/папка не существует или текущий пользователь не имеет доступа к данным? Можно ли просто установить 404 или 403 HTTP-коды ошибок или им нужно вернуть какой-то HTML-код? Что, если есть несколько причин для отказа, и я хотел бы передать это? Должен ли я произвольно выбирать коды ошибок HTTP или определять целые коды возврата, такие как 0, 1, 2 и т. Д.? Кроме того, должен ли URL указывать, что они JSON, например listFoldersJSON вместо listFolders?

Answer 1

Я использовал JSON в своих предыдущих проектах. Для ошибок мы возвращаем коды ошибок.

Мы решили сделать это, потому что имеем дело с клиентами API. Поэтому мы хотим иметь дело с кодами ошибок (REST основан на HTTP, поэтому было бы целесообразно возвращать коды ошибок).

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

довольно много if-else на вид. Кроме того, вы можете возвращать коды ошибок и проверять код перед рендерингом JSON в любой вид, который вы хотите.

Я бы пошел с ошибками, потому что это соответствует философии REST.

Answer 2

Вообще говоря, я обрабатываю эту ситуацию, бросая ошибку внутреннего внутреннего сервера с сообщением о состоянии. Большинство клиентских библиотек, таких как JQuery обеспечивают встроенные в обработку ошибок с недостаточностью функции обратного вызова, как:

jQuery.ajax({ 
    success:function(response){ 
     //do some success stuff 
    }, 
    error:function (xhr, ajaxOptions, thrownError){     
     //handle error 
     alert(xhr.responseText); 
     }  
}); 

Answer 3

Это вполне осуществимо, чтобы возвращать объекты JSON в отличие от действительных взглядов.

Что касается URL-адреса, вы можете использовать listFolders и listFiles, не принимая JSON. Однако я рекомендую вам использовать строчные URL-адреса для настройки сервера. Например, я знаю в Apache, что иногда listFiles будет в порядке, но listfiles приведет к отсутствию исключения страницы.

Что касается ошибок: вы можете настроить заголовок в своем ответе JSON и использовать любую систему, которая вам нужна.Например, вы могли бы сделать что-то вроде

status_code: 0 //where 0 means successful 
status_detail:success! 

Где, если status_code нечто иное, отличное от 0, вы бы проверить status_detail и знать, чтобы игнорировать все остальное внутри ответ.

Answer 4

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

Это основные коды HTTP Error:

• 401: Несанкционированные
• 404: Не найден

Там целое множество сообщений об ошибках в HTTP спецификации: HTTP Status Code Definitions

Кроме того, должен ли URL указывать, что они JSON, например listFoldersJSON вместо listFolders?

Как правило, хороший способ справиться с этим для клиента, чтобы установить «принимает» заголовок на что-то вроде «текст/JSON» или «текст/XML» и для сервера, чтобы разобрать его и ответить правильный ответ. Таким образом, вы можете использовать один и тот же URL-адрес, но отправлять разные представления данных (если вы когда-либо хотели)