Беспокойство при понимании протокола REST, поэтому подумал о том, чтобы связаться с экспертами здесь. Просьба уточнить.
REST советует не поддерживать состояние сервера. REST также советует получать ресурсы иерархически, по одному уровню за раз. Учитывая и то, и другое, считается, что сервер сталкивается с трудностями при повторной выборке записей из БД вместо фильтрации уже существующего фрагмента. Например, если какое-либо приложение должно получить информацию о континенте, форма URL REST будет иметь вид http: // host: port / fetchSomeInfo / ContinentName. В ответ приложение возвращает название «Все страны», и клиент доволен этим. Проблемы начинаются здесь, когда потребуются дополнительные подробности. В содержимом ответа, если Клиент запрашивает любую страну, чтобы получить города, теперь URL-адрес REST будет иметь форму http: // хост: порт / fetchSomeInfo / ContinentName / CountryName. Поскольку сервер не поддерживает состояние, он должен повторно запустить запрос к БД с ContinentName и CountryName. Далее, повторный запуск запроса происходит на каждом уровне: информация о городе в стране, информация о районе в городе. Чем больше идет иерархия, тем больше условий AND добавляется к запросу БД и каждый раз запускается повторно. Это хорошая стратегия дизайна?Can't load full resultsTry againRetrying...Retrying...

0
Kepler186f 23 Фев 2016 в 19:02

2 ответа

Лучший ответ

Не обязательно. Центральная концепция RESTful API заключается в том, что каждый ресурс имеет уникальный URI. Как правило, вы будете использовать пути, позволяющие быстро извлекать данные, например значения PK.

В вашем примере получения конкретного континента с определенной страной более подходящим URI будет: http: // host / Continents / continentID / Country / countryID

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

Таким образом, потребитель службы RESTful должен:

  1. ПОЛУЧИТЬ http: // host / continents
  2. Выполните поиск данных континента, чтобы получить идентификатор нужного континента.
  3. ПОЛУЧИТЬ http: // host / continents / id / countries
  4. Найдите данные о стране, чтобы получить идентификатор желаемой страны
  5. ПОЛУЧИТЬ http: // host / continents / id / countries / id

Но потребитель также может свободно хранить идентификаторы для использования в будущем, что позволяет ему напрямую: GET http://host/continents/id/countries/id

Что касается вашего беспокойства по поводу повторного выполнения запросов к БД , поскольку службы RESTful не поддерживают состояние, они потребляют гораздо меньше ресурсов. По сути, это службы, насыщенные базами данных. Но реляционные базы данных чрезвычайно оптимизированы для извлечения данных, особенно при правильной индексации для общих условий запроса.

В такой ситуации я бы подчеркнул распространенное предложение: Избегайте ранней оптимизации, это убьет ваш проект. Оптимизируйте, когда возникает необходимость в оптимизации

В общем, если ваша служба RESTful хорошо спроектирована и ваша БД хорошо структурирована, я сомневаюсь, что вы столкнетесь с какими-либо проблемами производительности из-за повторяющихся запросов к БД.

0
Sebastien Daniel 23 Фев 2016 в 16:13

RESTfulness не раскрывает внутренние детали, а описывает поведение службы. Следовательно, он должен вести себя без сохранения состояния. То, что вы задаете в своем вопросе простыми словами: «Могу ли я использовать кеширование, хотя я реализую успокаивающую службу?». Ответ положительный. Пока ваш сервис ведет себя правильно.

0
bitrecycling 23 Фев 2016 в 16:13