1) Почему REST:
Просто подумайте о паттерне MVC.
Разделение между моделями и представлениями особенно целесообразно, если у вас есть несколько представлений одного и того же контента.
Теперь представьте, что REST - это дружественный для машины вид через протокол конкретного приложения, который легко реализовать.Создание приложения также полезным для других разработчиков, которые хотят интегрировать ваше приложение в качестве веб-службы в свои собственные приложения.
REST - это технология интеграции приложений.
REST - хороший выбор, если вы хотитепредложить вашему приложению API-интерфейс, дружественный к машине и разработчику.
2) REST против RPC REST по определению должен реализовываться без сохранения состояния.Вызовы RPC - это удаленные вызовы методов для объектов или переменных сеанса, что делает API-интерфейсы RPC сохраняющими состояние и во многих ситуациях более дорогостоящими.
3) Различные стили REST Проблема с REST заключается в том, что не всегда легко отобразить все операцииобъект на общих HTTP-методах GET, POST, PUT, DELETE, OPTIONS.
Очевидно, что CRUD можно реализовать, назначив 4 операции CRUD методам GET, POST, PUT, DELETE.
Но вы также можете кодифицировать в теле HTTP метода POST вид операции, который является минималистичным стилем GET, POST для выполнения REST.
Проблема не в том, что все клиенты HTTP могут отправлять запрос PUT.
Решение, поддерживаемое службами стиля CRUD, заключается в том, чтобы эмулировать запрос PUT путем аннотирования запроса POST специальным заголовком HTTP:X-HTTP-Method-Override: PUT
Но это не решает проблему, потому что некоторые экзотические брандмауэры удаляют этот нестандартный заголовок HTTP.
Рой Филдинг, который придумал термин RESTful API,упоминает также, что, по его мнению, вполне возможно спроектировать совершенно RESTful-систему, используя только GET и POST.
4) Для добавления REST в существующее веб-приложение MVC требуется как минимум реализация дополнительного контроллера RESTful, который переводитВ HTTP-методе команды PUT, POST, DELETE используются для операций над объектом модели, идентифицируемым URI запроса, но часто также для реализации более удобного для машины представления (JSON, XML, ...).