Використання WebAPI або MVC для повернення JSON в ASP.NET

Я будую додаток ASP.NET MVC, який є важким для клієнта-скрипту, він використовуватиме JSON та jQuery для маніпуляції з DOM.

Я розумію, що контролер Web API і контролер MVC можуть повернути JSON.

З огляду на мій сценарій, чи варто використовувати контролер Web API або контролер MVC ?

Контролери Web API можна створювати та розміщувати в будь-якій програмі ASP.NET, а не лише у програмах MVC. Таким чином, очевидною причиною створення веб-API є те, що у вас немає MVC-інтерфейсу (наприклад, класичні, RESTful веб-сервіси, розміщені вашою компанією / організацією.)

Контролери MVC зазвичай покладаються на MVC Framework, якщо ви подивитеся на шаблони за замовчуванням і більшу частину роботи, яку виконують громада та ваші колеги, ви помітите, що майже всі контролери MVC реалізовані з урахуванням Перегляду.

Особисто я використовую контролери MVC, коли я маю намір відповісти з View (), і я буду використовувати веб-API для всього, що не залежить від конкретного виду.

Звичайно, є застереження, але загалом кажучи, якщо вам не потрібна поведінка моделей прив'язки MVC, ваша послуга орієнтована на дані, а операції орієнтовані на дані (наприклад, операції CRUD), то, швидше за все, ви хочете "Контролер веб-API "замість" контролера перегляду моделі ". І навпаки, якщо ваші операції орієнтовані на вигляд (наприклад, надання користувачу сторінки адміністратора користувача), або вам потрібна прив'язка моделі MVC для створення "ajax partals" (дуже малоймовірно), тоді вам потрібен буде MVC Controller.

Особисто я використовую контролери Web API для управління RESTful клієнтами на базі JSON, я використовую контролери MVC для обробки базової маршрутизації браузера та доставки SPA.

WebAPI призначений для створення API. Якщо ви хочете, щоб хтось міг споживати ваш API в XML, JSON тощо. Ви можете зробити веб-програму.

У вашому випадку вам потрібно лише поговорити з клієнтом у JSON.

Незважаючи на те, що ваш веб-сайт в основному керується сценаріями клієнтів, ви все одно будете використовувати ASP.NET MVC Controller так? А оскільки ви, можливо, вже логічно розділили свої контролери на основі сутностей, то має сенс додати в нього ті методи обслуговування json, на відміну від створення іншого класу спеціально для веб-api.

Тому для вашої конкретної ситуації (якщо я правильно розумію), я б дотримувався контролерів.

Відповідь зводиться до відокремлення проблем, прискорення створення служб і покладання на конвенцію, а не на конфігурацію.

Основна відповідальність контролерів полягає в тому, щоб працювати як координатор між представленням та вашою моделлю, але там, де головним обов'язком API є робота над даними. Що стосується конвенцій API, то це робить дійсно простим виконання операцій із CRUD. Нижче наведено відображення між операцією CRUD та HTTP-діями

• ЗАРАЗ: Прочитайте
• POST: Створіть
• PUT: оновлення
• УВАГА: видалити

Отже, для API не потрібно створювати окремі дії та присвоювати їм дії HTTP.

Єдине занепокоєння, яке я маю з ApiController, - це те, що він базується на веб-сайтах, а не на місцях. На одному веб-сайті може бути лише одна підпапка apicontroller для назви методів контролера. Можливо, вам потрібно скопіювати ім'я контролера в різних областях:

domain.com/api/area1/controller1/

domain.com/api/area2/controller1/

Пам’ятаю, є деякі налаштування коду, щоб це зробити, але це не працює за замовчуванням.

Я погоджуюся з відповіддю Шауна Вілсона (головна відповідь), але не впевнений, чому я просто трохи розгублений і все ще намагаюся зрозуміти з таким (мабуть, неправильним) передчуттям -

• Використовуйте WebAPI Controller, щоб доставити клієнтові дані JSON, щоб клієнт міг обробляти маніпуляції з переглядом. Цей процес не вимагає перегляду, а просто відповідь на метод, який називається (тобто запит JavaScript), щоб клієнт міг обробляти будь-які маніпуляції на стороні клієнта.
• Використовуйте контролер MVC, коли вам потрібно використовувати дані для маніпулювання поданням під час завантаження сторінки або відразу після неї (тобто не для програм SPA).

Розумієте, я просто не знаю, як я тут неправильний, і я розгублений, оскільки в останньому рядку відповіді Шауна зазначено: "Я використовую контролери MVC для обробки базової маршрутизації браузера та доставки SPA". - можливо, я не повністю знаю, що таке спокійний клієнт, коли я припускав, що це може бути метод JavaScript, який отримує відповідь у формі JSON. це найближчий пост у Stackoverflow, який був віддалено пов’язаний як відповідь на моє запитання, тому я відповідаю на це повідомлення замість можливих дублюючих питань.

У цьому випадку я б рекомендував WebApi, оскільки він ідеально підходить для передачі таких даних на основі запитів Javascript. Я зазвичай розробляю свої контролери WebApi, щоб вони повертали об'єкт, що відповідає JSON, який потім можна легко проаналізувати моїм Javascript.

Єдиним реальним часом, коли ви хочете використовувати дію на контролері MVC для подібних речей, було б, якщо ви хочете створити якийсь HTML і замінити сегменти вашої сторінки на дзвінки Javascript.

Наприклад:

У вас є JQuery UI Datepicker, який після вибору генерує список радіо кнопок, що представляють події в обраний день.

У цьому сценарії ви можете використовувати WebApi, щоб повернути деякий JSON, а потім генерувати необхідний HTML за допомогою Javascript, але загалом це погана практика створювати багато HTML за допомогою Javascript. Було б набагато краще, щоб C # нарощував HTML, а потім повертав його за допомогою часткового перегляду, оскільки таким чином ви рідше стикаєтеся з помилками при аналізі Javascript. Не кажучи вже про те, що HTML набагато простіше писати.