проектирующий API-интерфейс: именование URI, пользовательских заголовков? - PullRequest
3 голосов
/ 25 октября 2011

РЕДАКТИРОВАТЬ: я решил свои проблемы (на данный момент, по крайней мере).

Я недавно работал с Zendesk REST Api и их использованием пользовательских "X-Заголовок «On-Behalf-Of» для поиска билетов, открытых конкретным пользователем, заставил меня задуматься о выборе дизайна Restful Api (без конкретного языка, больше о том, как назвать вопрос URI).Я также прочитал этот связанный вопрос о пользовательских HTTP-заголовках , но он оставил мне больше вопросов, чем ответов.

Скажем, у меня есть пример спокойного веб-сервиса, работающего с приложениями для съемных квартир, где клиентыиспользуйте Basic Auth (оставьте это простым) для аутентификации.Определите базовые данные следующим образом:

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

Я изо всех сил пытаюсь правильно смоделировать URI для ресурса Applications в целом, и более конкретно в отношении роли клиентов.(предположим, что корень API - https://api.example.com/)

Как мне разрешить Арендодателю получать список отправленных им приложений? Моя интуиция говорит, что делает запрос "GET / Applications", и Basic Auth сообщает серверу, какойпользователь для создания списка, аналогично «GET / Applications», запрошенный Арендатором, вернет список отправленных им приложений… но я не уверен, что в целом это надежная схема, позволяющая смешивать и сопоставлять отправителя исписки получателей с одним и тем же URI. Должен ли я думать о ресурсе «/ Applications» по-разному, и, возможно, вместо этого разрешить использовать иерархию типа «/ Applications / [USER_IDENTIFIER]» для каждого пользователя?

Кроме того, независимо от моегоРазработка URI приложений, предположим, что Арендодатель может создавать приложения от имени арендатора. Лучше ли это сделать, отправив пользовательский заголовок, такой как «X-Create-On-Behalf-Of: somerenter@example.com» с помощью PUT /Запрос создания POST? Или моя схема должна определить поле, которое учитывает этот альтернативный сценарий.

Я оченьЭто любитель, поэтому я открыт для любой критики моих предположений / дизайна, а также любых указаний для получения дополнительной информации о разработке RESTful API.Спасибо за прочтение.

1 Ответ

2 голосов
/ 26 октября 2011

Я думаю, что нашел решение.

Арендодатели и арендаторы - это на самом деле просто подклассы одного и того же объекта, который я назову Стороной (как стороной сделки, а не днем ​​рождения). Таким образом, каждый из них имеет свой собственный ресурс, названный как / party / PARTY_ID.

Это легко расширить, чтобы увидеть, что / party / SOME_LANDLORD / приложения и / party / SOME_RENTER / приложения решают мои проблемы. Это также устраняет необходимость учитывать пользовательские заголовки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...