Как пример в стиле RPC будет выглядеть в стиле ресурса

Question

Я читал в Интернете о REST в течение нескольких дней и борюсь с концепцией HATEOAS.

Я думаю, что я боюсь, потому что я не правильно понимаю, как моделировать данные как ресурсы и (переходные состояния?) Между ресурсами. Я считаю, что моя проблема заключается в том, что весь мой опыт - это OO и RPC, и я не привык думать с точки зрения ресурсов.

Единственный способ получить понимание - это взять пример из моего мира, сказать, что я думаю, что это может выглядеть как смоделированное в стиле ресурса/ссылки, и выбросить его там, чтобы его сбили в огне. После того, как ожог закончен, я должен хотя бы лучше понять, чего не понимаю.

My (упрощенный) пример:

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

Если я реализовывал это в RPC образом я мог бы выставить два метода для вызывающих абонентов:

ListOfJobs GetJobs(search parameters) 
StartJobResult StartJob(jobID, optional start datetime) 

Как вы можете видеть, я имею в виде объектов и операции.

Если бы я думал о ресурсах и ссылках, какими могут быть ресурсы?

Моя догадка:

• Исполнитель: ~/подрядчик/plumbersareus?
• JobSearch: ~/подрядчик/plumbersareus/search/searchidentifier?
• Работа: ~/job/12345?
• Посещаемость: ~/job/12345/attendances/attendanceidentifier?

Предполагая, что любое из вышеуказанных правильных (и я сомневаюсь, что это), что должны быть «findidentifier» и «attendanceidentifier»? У первого не было бы идентичности в моем мире RPC; это просто параметры. Последний будет идентифицироваться с помощью DateTime.

Какими могут быть ссылки (игнорируя ссылки на себя)?

• Подрядчик: ~/подрядчик/plumbersareus/поиск?
• JobSearch: ~/job/12345, ~/job/12346, etc?
• Работа: ~/job/12345/attendances?
• Посещаемость:?

Примите мои извинения, если это повторите вопрос и закройте его. (Я не мог найти повторение, но я, возможно, искал неправильные условия.)

Answer 1

Вы можете прочитать эти две большие книги:

• REST in Practice

• Restful Web Services

Вернуться на ваши вопросы. Более практичный способ мышления или применения REST в качестве отправной точки (по крайней мере, это работает для меня) заключается в следующем:

1) Используйте только HTTP 'GET/POST/PUT/DELETE' как способ для моделирования действий вашего домена. Как и при работе с базой данных, все ваши действия сопоставляются с CURD.

2) URI/URL предназначен для идентификации ресурсов. В вашем URI никогда не должно быть никаких «действий».

3) Обмен данными должен быть в теле HTTP-сообщений. Просто для упрощения обсуждений, а не для того, чтобы самим моделировать сами данные

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

Для модели 'получают работу':

• HTTP: GET
• URL: ~/подрядчиков/[plumberID]/Работа/

Для моделирования, поиска работы:

• HTTP: GET
• URL: ~/jobs /? [Некоторые параметры поиска]/

Для моделирования назначить задание на пользователя:

• HTTP: PUT
• URL: ~/подрядчиков/[plumberID]/задания/[JobId]

Есть некоторые различия в использовании PUT vs POST, вы можете искать вокруг.

Надеюсь, что эта помощь.