Что ж, здесь происходит пара вещей.
Во-первых, вы можете просто добавить ссылку на любой из ваших общих «глобальных» ресурсов. Как бы мне ни не хотелось сравнивать архитектуру REST с веб-сайтом, веб-сайт является здесь подходящим примером. Учтите, что многие ресурсы здесь, на SO, имеют ссылки на общие, «глобальные» ресурсы, такие как домашняя страница, / questions, / tags, / badges и / users.
Тот факт, что ресурс является «статическим» и никогда не изменяется, не влияет на то, делаете ли вы этот ресурс доступным в виде ссылки через другой ресурс как часть HATEOS, это ортогональная проблема.
Второй момент заключается в том, что нет ничего, что говорило бы о том, что вся служба будет постоянно доступна из любого ресурса. У вас могут быть «хорошо известные» точки входа в вашу службу, и они могут быть хорошо задокументированы (извне). Единственным недостатком является то, что если URL-адреса для определенного отношения изменяются (например, / questions to / questions-2), то эти URL-адреса не могут автоматически выбираться клиентами. Но это, вероятно, не проблема, поскольку, изменяя URL-адрес, вы, вероятно, измените что-то еще (например, полезную нагрузку), которое влияет на клиентов до такой степени, что старый клиент может оказаться несовместимым с новыми URL-адресами.
Также не проблема, чтобы клиенты «знали», где находятся объекты во вложенной системе. Например, если они «знают», как описано в документации, что они могут получить доступ к / version только из ресурса / home, а у каждого другого ресурса есть путь к / home (прямо или косвенно), то это не проблема. либо. Когда он хочет / version, он должен иметь представление о том, как его получить.
Пока клиент просматривает график, основываясь на том, что вы ему рассказываете, а не на том, что «он думает», все в порядке. Если клиент в настоящее время обрабатывает ресурс / blog / daily_news / 123 и у него есть ссылка на «родительский» с URL-адресом / blog, а в / blog есть ссылка rel «version» на / version, тогда клиент может пройти по графу (просматривая родительский объект rel для / blog и версию rel для / version). Чего клиенту не следует делать (если иное не задокументировано), так это того, что он не должен ПРЕДОСТАВЛЯТЬ, что он может посещать / версию, когда захочет. Поскольку на него нет ссылок из / blog / daily_news / 123, клиент не должен просто переходить к нему. Отеля там нет, поэтому клиент «не знает».
Это ключевой момент. Тот факт, что его там нет, означает, что это не вариант прямо сейчас по какой-либо причине, и это не задача клиента, чтобы заставить точку, поскольку пространство URL-адресов не в его руках, оно в руках служб. Это контролирует служба, а не клиент.
Если / version внезапно исчезнет, это уже другая проблема. Возможно, они истекли, и им больше не разрешено "видеть" / версию, возможно, вы удалили его. В этот момент клиент просто выдаст ошибку «не может найти версию rel» и затем завершит работу. Это не связанная с этим проблема, просто правда (что еще вы можете сделать, когда ресурсы внезапно исчезают за вашей спиной).
Дополнение к вопросу:
Что, насколько я понимаю, означает: если срок действия / home еще не истек, и мы переходим к / blog (который содержит ссылку обратно на / home), тогда методы rel в / home по-прежнему сразу же «доступны» из / blog, верно?
Нет, не совсем. Это ключевой момент. За исключением некоторых глобальных ресурсов, специально задокументированных (внеполосных), вам не следует переходить по какой-либо ссылке, не указанной в вашем текущем ресурсе. Срок действия / home не имеет значения вообще.
Сервер, безусловно, мог бы отправить соответствующие инструкции кеширования, сообщая вам, что вы можете кэшировать / home в течение некоторого времени, но вы все равно должны пройти через rel to / home, чтобы получить любые ссылки, которые, по вашему мнению, там есть.
Если / home хорошо кэшируется на вашем клиенте, то этот обход фактически бесплатный, но логически и семантически вы должны придерживаться протокола обхода ссылок.
Потому что, если он НЕ кеширован, вы просто не знаете, какие rels будут там, когда вернетесь. Да, в 99,999999% случаев он всегда будет одним и тем же, и позор серверу за то, что он не отправил соответствующие заголовки кеширования, но по определению сервер ничего вам не обещает, поэтому и вы, и клиент, и он, сервер, съедайте затраты на обработку из-за многократного обращения к эффективно статическому ресурсу.
Поручая своему клиенту следовать инструкциям, возможно, с внутренней оптимизацией из-за кэширования и предварительной обработки, чтобы сделать эти статические обходы быстрыми и эффективными, вы придерживаетесь модели HATEOS и перекладываете на систему, чтобы сделать ее оптимальной, а не предполагать на уровне кода и перепрыгивая через rels, которые, как вы думаете, у вас уже есть.
Таким образом, ваш код будет работать всегда, независимо от того, что делает сервер. Кто знает, когда они могут включить или выключить кеширование, ваш код определенно не должен заботиться о том, чтобы решить, разыменовать ли ссылку определенно или нет.
Предпосылка HATEOS заключается в том, что сервер отвечает за свое пространство URL-адресов и передает его под мандат. Произвольные прыжки без указаний со стороны сервера не соответствуют требованиям, это не ваш график для навигации. REST предназначен для более грубых операций, но правильное кеширование и тому подобное может сделать переход через эти обручи быстрым и эффективным для вас, клиента.
person
Will Hartung
schedule
24.07.2013
