Как организовать URL? - PullRequest
Новая
       22

Как организовать URL?

0 голосов
/ 12 февраля 2011

Предположим, у меня есть веб-приложение с несколькими модулями, которые существуют как на сервере, так и на стороне клиента. Каждый модуль имеет несколько URL-адресов серверов для доступа / манипулирования данными для этого модуля. Предположим, у нас есть «блоги» в нашем приложении.

Например, URL-адрес сервера для получения блога может быть /blogs/getBlog, а для сохранения блога - /blogs/saveBlog.

Для клиентской стороны я вижу два варианта:

  1. Храните URL-адреса в одном классе менеджера URL-адресов. Например, он будет содержать свойство с именем getBlogUrl и saveBlogUrl, а также другие (аналогичные) свойства для остальных модулей.
  2. Хранить URL-адреса в каждом отдельном модуле. Например, класс Blog может иметь ранее упомянутые URL-адреса как свои свойства.

При проектировании ваших систем, какую из них вы бы выбрали и почему? Есть ли другие варианты, которые вы могли бы использовать для организации ваших URL?

Ответы [ 2 ]

2 голосов
/ 02 марта 2011

Я лично предпочитаю схемы URL, которые следуют шаблону глагола субъекта.Например: 

/blog/new
/blog/{blog_id}
/blog/{blog_id}/newpost
/blog/{blog_id}/edit

Обратите внимание, что составные предметы в порядке: 

/blog/{blog_id}/post/{post_id}
/blog/{blog_id}/post/{post_id}/edit

Как правило, вам не нужно больше двух идентификаторов.Если он становится более сложным, вы можете создать защищенный URI буфер протокола , который объединяет несколько идентификаторов в непрозрачный составной идентификатор, который можно десериализовать в его составные части на стороне сервера.Таким образом, вместо: 

/blog/{blog_id}/post/{post_id}/comment/{comment_id}

Использование: 

/comment/{merged_id}

Возможно, вы захотите оставаться последовательным.Старайтесь избегать смешивания и сопоставления плоских и иерархических схем URI.Это может сбивать с толку.

В частности, для API вы, как правило, хотите добавлять префикс к /{api_name}/{api_version}/, потому что, как выясняется, внесение критических изменений в API не делает вас привлекательными для людей, использующих ваши API,Управление версиями позволяет любым разработчикам ваших API-интерфейсов обновлять их по своему усмотрению и дает вам возможность изящно, а не единовременно отказываться от устаревших форматов и схем URI.

Если клиенты отслеживают, какие URI вызыватьОдин из вариантов - предоставить механизм обнаружения.Это то, что Google делает для наших клиентов API следующего поколения.Клиенты могут автоматически обнаруживать структуру URI из документа обнаружения вместе со списком обязательных и необязательных параметров.Это позволяет повторно использовать клиентов для нескольких API и позволяет разработчикам работать либо в стиле RPC, либо в стиле REST, в то же время отделяя большую часть логики.Конечно, этот подход требует гораздо больше предварительных усилий, но он того стоит, если ваша система достаточно сложна или если у вас достаточно API, чтобы обслуживание клиентов M API × N языков клиентов становилось несостоятельным.

1 голос
/ 13 февраля 2011

Я бы попробовал другой подход - идентифицировать модули по идентификатору модуля - просто какая-то уникальная строка, не основанная на расположении модуля. Пусть серверные модули регистрируются с идентификатором и списком путей (относительных URL) к модулю реестра.

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

В клиенте вы можете использовать одноэлементный (?) Модуль реестра с методом getUrls (moduleId), и все модули могут читать его отсюда. Таким образом, в клиентском модуле хранится только идентификатор, который не должен изменяться, а также модуль реестра имеет простой и стабильный интерфейс.

...