Итак, я создаю REST api, и я изо всех сил стараюсь обрабатывать глубоко вложенные отношения. Вот пример некоторых из ресурсов я имею:REST API, связанный с вложенными отношениями
Профили - пользователь может быть клиента или поставщика профилем.
Событие - клиентские профили могут создавать события
Задачи (например, социальные события, которые имеют атрибуты, такие как время, имя, расположение и т.д.). - Под событием, профиль клиента будет создавать «задачу», которые необходимо который должен быть заполнен профилем поставщика для события THAT (например, задачей может быть предоставление услуги фотографии для события).
Работа просит - После того, как профиль клиента создает задачи для их событий, они могут посылать запросы на работу для каждой задачи в профили поставщика (здесь профиль поставщика имеет возможность принять запрос на работу и стать Наемным/СВЯЗАННЫМИ к задаче).
Я также использую схему аутентификации на основе токенов.
Мой вопрос: Как я должен конструировать URL-адреса? Я размышлял над созданием плоских URL-адресов, которые понравились /tasks/ и /profiles/, но понял, что мой проект очень иерархичен и требует большего контекста. Например, профиль клиента может потребоваться, чтобы увидеть работу, запрос послали поэтому URL может выглядеть:
/profiles/id/events/id/tasks/id/job-requests/id
Я невероятно неохотно поддерживать такую сложную древовидную ориентированный URL. Какой из них лучше подходит для моего сценария и почему?
Помимо выбора между плоскими или ориентированными по дереву URLS, мне нужно предоставить различные формы данных для одного и того же ресурса. Например, клиент может захотеть получить доступ к своей созданной задаче и поэтому должен иметь FULL ACCESS для всех атрибутов этой задачи, тогда как после того, как поставщик связан с задачей (после принятия запроса на работу), они могут видеть только некоторые атрибуты задачи. В этом случае можно видеть, что требуется некоторая форма разрешения, и, следовательно, необходимо предоставить дополнительный контекст? Если это так, , как мне следует предоставить больше контекста? Я рассмотрел два варианта:
- Стики с деревом ориентированной URL-адресами, которые привели бы к этим 2 URLs:
/profiles/id/events/id/tasks/id(профиль клиента доступа к их созданной задаче для случая)/profiles/id/job-requests/id(профиль поставщика доступа задания профиля клиента, где они есть было наняли/связанный.) - Придерживайтесь плоскими URLs (
/tasks/id/) как для профиля клиента и профиля поставщика, однако, как только они обеспечивают их уникальный аутентификация маркера, я могу сопоставить его с их профилем и обеспечиваю необходимое и разрешенные данные автоматически.
В качестве примечания: Вы можете быть удивлены, почему я клиент и поставщик профилей под
/profiles/
Это потому, что оба этих профили имеют очень схожие атрибуты данных и пользователь системы может иметь несколько профили (например, лицо A имеет профиль клиента и поставщика и может переключаться между ними).
Спасибо :)