RESTFful/Resource Oriented Design

Question

Предположим, у меня есть иерархия уровня, состоящая из школы, учеников и классов.

Если я выставляю ученика в качестве ресурса, мой вопрос заключается в том, должен ли я всегда возвращать родительскую «школу» и «классы» детей вместе с этим учащимся, или должен быть парм, который пользователь включает в себя, чтобы указать его. Возможно, что-то вроде & deep = True?

С другой стороны, если пользователь получает студент, и он хочет школу, он должен сделать ПОЛУЧЕНИЕ на школьном ресурсе, а также, если он хочет всех классов, которые принимает учащийся, у него есть выполнить GET на ресурсе классов?

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

Спасибо,

Нил Walters

Answer 1

Я думаю, вам следует избегать думать о классах как о субресурсе или атрибуте ученика. Академический класс - это больше, чем просто временной график по расписанию ученика; у него есть инструктор, учебный план и т. д., все из которых, возможно, необходимо будет закодировать в какой-то момент.

Как я понимаю, справедливы следующие соотношения:

• школы имеют ноль или больше студентов
• школы ноль или более классов
• студентов имеют нулевой или более классов
• классы имеют нулевой или более учеников

(Вы также можете тривиально расширить их с помощью учителей/инструкторов, если ваше требование nts включили такую ​​информацию.)

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

Учитывая, что, я думаю, вы хотите структуру URL что-то вроде следующего:

• http://example.com/lms/schools => список школ
• http://example.com/lms/schools/{school} => Информация о школе один
• http://example.com/lms/schools/{school}/students => список студентов
• http://example.com/lms/schools/{school}/students/{student} => Информация о один студент
• http://example.com/lms/schools/{school}/students/{student}/courses => список курсов (как ссылки, не все ресурсы) студент поступил в
• http://example.com/lms/schools/{school}/courses => список курсов
• http://example.com/lms/schools/{school}/courses/{course} => Информация о один курс
• http://example.com/lms/schools/{school}/courses/{course}/students => список студентов (как ссылки, не полные ресурсы) зачисленных в курс

Answer 2

Я полагаю, что добавление параметров запроса для оптимизации доставки является разумным. Я мог бы сделать его еще более общим и использовать include=<relation>. Это может быть расширено для всех типов. Обратите внимание, что вы можете использовать несколько включений: .../student/<id>?include=school&include=student назначит список [school, student] параметру include. Это также позволит использовать общую схему, которая может быть полезной и для других ресурсов.

Answer 3

Если вы думаете о дизайне ресурсов больше в том, как вы думаете о дизайне пользовательского интерфейса, проблема становится проще. Там нет причин, почему вы не можете вернуть подмножество информации школы в представлении студенческого ресурса, а также возвращает ссылку на полное представление школьного ресурса в случае, если пользователь хочет видеть больше.

я считаю полезным думать интерфейс REST больше похож на интерфейс пользователя для машин вместо слоя доступа к данным. С этим мышлением не является проблемой дублировать информацию в разных представлениях ресурсов.

Я знаю, что есть много людей, пытающихся обработать REST, как DAL, но они те же люди, которые расстраиваются, когда выясняют, что вы не можете совершать транзакции через интерфейс RESTful.

Положите другой способ, создайте свой API так, как если бы вы разработали веб-сайт (но без каких-либо хороших вещей), а затем создайте клиента, который может сканировать сайт для необходимой ему информации.