Являются ли сервисные URL * .local RESTful?

Question

URL предположительно находит (а не просто идентифицирует) ресурс;Следствием является то, что один и тот же URL-адрес должен ссылаться на один и тот же ресурс.Однако это правило может быть нарушено в случае URL-адресов, таких как http://api.local/orders/333, в которых api.local не разрешается для хоста для всех и может даже не разрешаться на тот же хост в случае, если он разрешается.(Например, вы можете указать api.local на один хост в среде разработки, а другой в живой среде.)

1. Строго говоря, URL-адреса с именем хоста, например api.local (или 127.0.0.1) RESTful?
2. Есть ли проблемы, которые может вызвать этот подход?
3. Есть ли хорошие альтернативы?(Что лучше: http://flickr/ или http://flickr.local/ или http://flickr.api?)

Answer 1

URL не являются RESTful. Приложения RESTful (или нет), но URL-адреса нет. Фактически, в приложении RESTful URL-адреса совершенно не имеют значения, поэтому сам факт того, что вы беспокоитесь о том, являются ли ваши URL-адреса RESTful, показывает, что ваше приложение - нет. Но это не имеет ничего общего с URL.

Answer 2

URL означает « Uniform Resource Locator», а не « Universal Resource Locator». В URL нет ничего, что говорило бы о том, что он должен быть «глобально» или «универсально» доступен. Поэтому я не вижу проблемы с * .local для локального тестирования (для меня, конечно, было бы плохо иметь среду тестирования или разработки, доступную из в любом месте ).

Answer 3

Одна из основных практических проблем, связанных с тем, что «только один URL должен возвращать ресурс», связана с влиянием на кеши. Если у вас есть два URL для одного и того же ресурса, вы можете получить две копии в кеше. Если вы сделаете PUT для одного из них, то кеш должен аннулировать оба, но он не знает об отношении между двумя копиями.

Что касается проблемы, в которой вы используете имя хоста, которое может разрешаться для разных потоков байтов, в зависимости от того, откуда вы обращаетесь к нему, я не считаю это проблемой вообще. Концептуально вы обращаетесь к одному и тому же ресурсу, на самом деле это просто другой экземпляр этого ресурса. Я широко использую это как форму механизма обнаружения. Я разрабатываю корпоративное приложение, которое размещается на сервере, который я называю «TMServer». Внутри организации существует только один экземпляр TMServer, и все ресурсы доступны с этого хоста. например http://TMServer/Suppliers У одного из моих других клиентов этот же URL-адрес разрешит совершенно другой набор поставщиков, но концептуально он все еще является "списком поставщиков".

Если бы один из моих клиентов попытался поделиться URL-адресом с другой компанией, тогда URL-адрес нужно было бы расширить до чего-то вроде http://TMServer.company.com/Suppliers.. Тогда он станет универсально уникальным URI.

Используя псевдоним DNS, я легко могу использовать свой файл .hosts для перенаправления, на которое указывает TMServer для тестирования, и, добавив запись на DNS-сервере, я могу сообщить о доступности службы всем пользователям в сети.

Answer 4

URL-адрес определяет местоположение ресурса, указывая путь к этому ресурсу и протокол, используемый для доступа к этому ресурсу.Все ваши примеры одинаково RESTful.Они идентифицируют ресурс относительно клиента REST, к которому хочет получить доступ клиент REST.

Клиент REST может свободно указать местоположение ресурса, к которому он хочет получить доступ.Клиент REST должен знать, что сервер api.local содержит или не содержит ресурс, к которому он хочет получить доступ.

Если ваш сервер REST намерен иметь универсально доступный ресурс, то вам следуетОтветьте ресурсом, который не найден, если он не запрашивает правильный URL.

Вполне допустимо, что у вас есть ситуация, когда у вас есть REST-сервер на локальном компьютере, а другой - в Интернете.Клиент REST будет указывать, какой бы он ни захотел получить доступ.

При этом не самый лучший дизайн - иметь много разных URL, ссылающихся на один и тот же ресурс.Так что нет ничего плохого в использовании api.local, но лучше разрешать такие вещи, когда api.local и api ссылаются на разные ресурсы.