Концептуальное понимание REST с помощью Rails

Question

Я немного опоздал на вечеринку, но я пытаюсь обдумать, как REST должен работать, как в целом, так и в Ruby on Rails. Я уже читал кучу статей в Интернете об этом, но все еще не чувствую, что получаю полную картину.

REST, насколько я понимаю, представляет собой серию желательных утверждений, с чистым результатом в нижней части является то, что URL-адреса должны содержать всю информацию, необходимую для обработки запроса, а get не должен иметь возможность изменять состояние на сервере и множество других конкретных рекомендаций.

Насколько я понимаю, REST в Rails основан на CRUD, то есть каждая модель имеет действие создания, чтения, обновления и удаления. Каждое из этих действий доступно через аналогичный набор URL-адресов, созданных путем сопоставления ресурса в маршрутах. Таким образом, URL-адрес входа создает сеанс пользователя, поэтому URL будет выглядеть как example.com/session/new с POST, а выход из системы будет example.com/session/destroy с POST.

В чем именно заключается преимущество стандартизации URL-адресов таким способом? Мне кажется, что это оптимизирует машинную читаемость за счет читаемости человеком. Я знаю, что затем вы можете переназначить в файле маршрутов example.com/login на example.com/session/new, но это еще один шаг без видимой выгоды для меня.

Считается ли действительно плохой практикой создание веб-сайта, использующего традиционные маршруты?

Кроме того, каждое из этих действий CRUD должно иметь возможность отвечать на запросы любым типом ответа, который ищет запрос. Так, например, ту же ссылку на, например, example.com/tasks можно также вызвать по адресу example.com/tasks.xml для получения xml-представления результата или example.com/tasks.json для json-представления.

Это значит, что RESTful API будет просто обычными ссылками на сайте, но с добавлением xml? Мне кажется очень странным и неловким, что веб-API будет вести себя таким образом, но, похоже, это то, что подразумевается под всем, что я читал. Я более привык видеть API, на котором есть ссылки, например example.com/api/tasks, чтобы получить список задач. В чем именно преимущество этого подхода?

Answer 1

Rest предоставляет еще один фрагмент «соглашения о конфигурации». Для широко используемого ограниченного набора общих проблем (грубые действия против моделей в целом) отдых очень полезен в качестве соглашения о разработке приложений.

Что именно является преимуществом стандартизировать URL таким способом?

Эффективность программиста. Меньше думать; позволяет тратить больше времени на более сложные проблемы и т. д. Лучшая ремонтопригодность. Более легкое тестирование. И т.д.

Считается ли это действительно плохой практикой? разработать сайт, который использует традиционные маршруты сейчас?

Да, для грубых действий, которые взаимодействуют со всей записью модели.

Кроме того, каждый из этих CRUD действия должны быть в состоянии ответить на запросы с любым типом ответ на запрос ищет. Так же ссылка на, скажем, example.com/tasks также можно назвать на example.com/tasks.xml, чтобы получить xml представление результата, или example.com/tasks.json для JSON представление.

Это значит, что RESTful API будет просто обычные ссылки на сайт, но с добавлением XML?

Да, если ваш API подходит для остальных моделей. Я думаю, что большая проблема - аутентификация. Если вы хотите, чтобы ваш API не имел состояния, тогда вам, вероятно, нужно будет включать аутентификацию для каждого звонка. В этот момент, если вы не хотите использовать проверку подлинности на уровне HTTP, вам необходимо решить, как включить учетные данные.