означает ли возможность обнаружения REST и HATEOAS, что вы можете изменить URI?

Я пытаюсь прояснить концепцию, связанную с возможностью обнаружения REST, то есть означает ли соответствие ограничению HATEOAS для службы RESTful, что теперь URI могут изменяться, потому что они доступны для обнаружения и не документированы.

Кажется, это не соответствует концепции классных URI — тот факт, что URI не никогда не изменится. Это также несколько не соответствует модели самой сети (которой REST, по сути, должен идеально подходить) — тот факт, что URL-адреса можно добавлять в закладки и они никогда не меняются, и тот факт, что вы, изучив один из них, можете перейти прямо к нему, и вы делаете не нужно проходить через корень и открывать его каждый раз.

Любые отзывы по этому поводу приветствуются.


rest uri restful-url hateoas discoverability
person Eugen    schedule 13.11.2011    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Для классных URI нет - вы никогда не должны их менять. Они являются точками входа в вашу систему. Однако их должно быть очень мало, если вы хотите иметь возможность развивать остальную часть структуры URI вашей системы в будущем.

Для любых неклассных URI они действительно могут меняться со временем. Недавно я написал запись в блоге на эту тему, потому что нашел REST способность позволить мне развивать мою систему с течением времени, чтобы быть невероятно полезной.

Убедитесь, что в документации по API указано, что только несколько классных URI в вашей системе должны быть жестко закодированы клиентами, а любые другие URI должны быть обнаружены во время выполнения посредством обхода гипермедиа. Думайте о них как об адресе указателя C: никого не волнует, какое шестнадцатеричное значение переменной указателя, но они, черт возьми, захотят, чтобы оно указывало на допустимое место в памяти. То же самое относится и к вашим неклассным URI — их структура не имеет значения, но тот факт, что они были получены во время выполнения через диалоги с вашим сервером, делает их действительными.

person Brian Kelly    schedule 13.11.2011
comment
Спасибо за быстрый ответ. Я прочитал статью, но мне до сих пор не ясны некоторые вещи. Во-первых, разве для этого не предназначено управление версиями API? и во-вторых, должна ли быть ЛЮБАЯ документация? Насколько я понимаю, в чистой реализации RESTful документации практически не будет. Было бы лучше использовать только классные URL-адреса и сделать другую версию API для таких радикальных изменений? - person Eugen; 13.11.2011
comment
Версионирование API исключительно для обеспечения совместимости структуры URI приводит к тем же проблемам, что и наличие WSDL для каждой версии веб-службы: вы не развиваете свою службу, вы добавляете новые (в основном дублированные) ее версии каждый раз, когда вы вам нужно будет тестировать, поддерживать, документировать и т. д. Сделайте это и попрощайтесь с огромным преимуществом REST: динамической эволюцией ваших контрактов и прекрасным разделением клиента и сервера. - person Brian Kelly; 13.11.2011
comment
А что касается отсутствия документации, конечно, когда весь мир программного обеспечения наработает опыт работы с REST, это будет иметь смысл. Всегда будут новички, которые захотят использовать ваш API, и давать им ничего для работы не имеет смысла. Конечно, эксперт по REST, вероятно, мог бы сесть и разобраться во всем этом, но это не тот мир, в котором мы живем. Задокументируйте ваши типы мультимедиа и семантику каждого ресурса и предоставьте пример кода, показывающий, как должны быть построены хорошо сконструированные клиенты, и вам будет хорошо. - person Brian Kelly; 13.11.2011
comment
Имеет смысл с прагматической точки зрения. Однако я больше думал о чистой реализации RESTful, прежде чем идти на компромисс. Что касается управления версиями и прагматичного подхода, меня интересует практический опыт использования API, который действительно используется большим количеством клиентов — можно ли это изменить? Прагматически я думаю, что это невозможно, и что управление версиями — единственный жизнеспособный путь, особенно в свете того факта, что есть и другие преимущества сохранения классных URL-адресов. Спасибо за интересный отзыв. - person Eugen; 14.11.2011
comment
Я не видел RESTful API, который развивался бы без управления версиями URI, и я думаю, что это связано с тем, что большинство программистов тяготеют к мышлению, основанному на контрактах, порожденному такими технологиями, как WSDL, CORBA IDL и т. д. Это абсолютно возможно с ОТДЫХАЙТЕ, чтобы отойти от этого мышления, и я призываю вас попытаться сделать то же самое. - person Brian Kelly; 14.11.2011

arrow_upward
0
arrow_downward

Должна быть документация. MediaTypes и Link Relations являются связующим звеном, и и клиент, и сервер должны это понимать. Вот почему HTML, ATOM и RSS имеют стандарты.

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

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

person suing    schedule 14.11.2011