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

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

Этобазовые коды ошибок HTTP:

• 401: неавторизовано
• 404: не найдено

В спецификации HTTP содержится множество сообщений об ошибках: Определения кода состояния HTTP

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

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

Answer 2

Вообще говоря, я справляюсь с этой ситуацией, выдавая 500 внутренних ошибок сервера с сообщением о состоянии.Большинство клиентских библиотек, таких как 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

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

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

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

в значительной степени if-else в представлении. В противном случае вы можете вернуть коды ошибок и проверить код перед тем, как преобразовать JSON в любое представление.

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