REST API - Лучшая практика для доступа к встроенным ресурсам

Мы используем MongoDB и предоставляем restful api для доступа к ресурсам (а не только к коллекциям). Например, у меня есть комплект устройств . Каждый документ устройства имеет встроенный массив : несущие. Это классы ассоциаций для операторов, без какого-либо уникального идентификатора.REST API - Лучшая практика для доступа к встроенным ресурсам

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

Вопрос: Какая самая прекрасная практика, требующая применения этих встроенных документов? Во многих случаях I GET/POST/PUT/DELETE их индивидуально.

В противном случае это всего лишь пример. У нас есть встроенные документы во многих других случаях.

Идеи:

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

источник

2015-10-21 hasyee

Чтобы быть честным, если вам нужно запросить конкретный ресурс с помощью REST API, лучше всего назначить ему уникальный идентификатор. Если вам просто нужна фильтрация коллекции, например. по * от * диапазона, будет полезен некоторый язык запросов ресурсов. – Opal

Последний случай готов и дополнен удовлетворительным языком запросов, как вы писали. В первом случае я думаю, что нет необходимости добавлять уникальный идентификатор, потому что указанные поля гарантируют уникальность. – hasyee

Полностью согласен, однако, введенный ID упростит запросы. – Opal

Насколько я понял, вам нужно получить доступ к элементам, которые не назначены никаким ID в RESTful пути.

Прежде всего, я бы добавил отдельную конечную точку только для носителей. Это будет:

/devices/{deviceID}/carriers/

Я не знаю, почему не назначить уникальный идентификатор на уровне Монго DB (это, кажется, самый простой вариант), но если это не возможно, то лучше обратиться к ресурсу с помощью искусственного составной ключ передается по пути, а не посылка параметров по строке запроса. Таким образом, каждый раз, когда вы вернуть коллекцию носителей присвоят каждый элемент:

carrierID = md5(carrier+from+to)

С таким ключом можно легко ссылаться каждый вложенный ресурс с помощью:

/devices/{deviceID}/carriers/{carrierID}/

Похоже, что это будет намного проще ссылаются на такие ресурсы через разные конечные точки.

Недостатком является то, что вам необходимо пересчитать carrierID для всех ресурсов на стороне сервера, чтобы проверить, соответствует ли кто-либо из полученных.

Я вижу, что у вас есть ObjectId для каждого поля несущей. Разве это не уникально? Почему бы вам не использовать его?

источник

2015-10-21 14:12:26 Opal

/devices/{deviceID}/carrier/ Это правильный путь в иерархии конечных точек. Но md5 нуждается в агрегировании в mongo-side, что должно подсчитать каждое значение md5, как вы сказали. ** carrierId ** не является уникальным в классе ассоциации, так как возможно, что одно устройство может находиться в разных интервалах в одной и той же несущей. Но я ошибаюсь, ** from ** значение является удовлетворительным для запроса. – hasyee

Итак, если 'from' выполняет требование уникальности, я бы использовал его как' carrierID'. Если вы не хотите передавать его явно, используйте md5 od other hash od it - это повлияет на производительность, как я уже писал. – Opal

В противном случае задается проблема, если для единственности имеется более одного параметра. Но! Я не ищу решение. Я могу это разрешить. Мне нужно самое красивое и общепринятое решение, если оно есть. – hasyee

REST API - Лучшая практика для доступа к встроенным ресурсам

ответ

Смежные вопросы