Я работаю над новым проектом iOS-приложения для мобильных устройств. Происходят некоторые изменения в архитектуре, и оказывается, что нам придется полагаться на собственный частный API, который будет использоваться приложением, которое мы создаем, а также другими клиентами, такими как веб-сайт.
Разрабатываемый API соответствует стилю Rest ресурсо-ориентированных операций URI и CRUD, сопоставленных с глаголами HTTP. вещи как:
GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793
Проблема заключается в том, что этот стиль часто приводит к тому, что мобильный клиент должен выполнять много запросов для загрузки одного экрана приложения или управления действием пользовательского интерфейса одного пользователя. Это приводит к тому, что приложение находится в режиме загрузки в течение 8 секунд, пока оно не будет иметь все необходимое. Медленное и неотзывчивое приложение.
Мобильные клиенты имеют серьезные ограничения, когда дело доходит до подключения, и в идеале мы должны следовать такому правилу:
1 экран == 1 вызов API
1 сохранить == 1 вызов API.
Есть много ситуаций, когда это приводит вас к столкновению с принципами проектирования REST, например:
- скажем, ваше приложение было в автономном режиме в течение дня, и вам нужно синхронизировать с четырьмя таблицами серверных баз данных, и вам нужен вызов, как
www.example.com/sync_everything?since=2015-07-24 - Допустим, есть экран, где пользователь может редактировать многие из своих объектов, например, отмечая галочкой задачи в своем списке задач. должен быть способ отредактировать все эти записи задач в одном пакетном вызове API, а не один вызов API на редактирование.
- скажем, есть экран, который смешивает информацию из таблиц БД ORDER, SALESMEN и PRODUCT, я должен получить эти данные за один вызов вместо трех.
риск состоит в том, что мы можем получить самый API-интерфейс Restful, а также самое бесполезное мобильное приложение без ответа.
Дело в том, что я всего лишь новый подрядчик, и мне нужно что-то, что поможет мне сделать эти выводы, некоторые статьи из уважаемых источников или что-то в этом роде. Основные игроки, которые идут на компромисс со стилем REST для своего мобильного клиента (например, с помощью составных совокупных конечных точек API).
Или любое решение для этой общей проблемы. Благодарность!
Ответы:
Это ваша проблема прямо здесь.
Вы ограничили свои ресурсы (я предполагаю) моделями в вашей базе данных. Таким образом, загрузка всех этих ресурсов занимает много времени, потому что ваш сервер не имеет понятия о ресурсах, которые не представлены в базе данных.
Например, может иметь
что все должно быть загружено, чтобы получить мою библиотеку
Это не проблема с дизайном RESTful, это настоящий анти-шаблон REST. В REST абсолютно ничего не говорится о том, что наши ресурсы должны иметь взаимно однозначное сопоставление с чем-либо еще в вашей системе, включая модели баз данных.
Решение состоит в том, чтобы создать больше ресурсов, которые лучше соответствуют тому, что вы хотите загрузить. Если у вас есть 5 ресурсов, которые всегда заканчиваются вместе, создайте новый ресурс, который содержит информацию для этих 5 ресурсов.
То, что вы должны иметь, это что-то вроде этого
который просто загружает все книги для этого пользователя. my_library не является моделью в вашей базе данных, но это ресурс. Сервер создает его на основе моделей в базе данных, но нет сопоставления «один к одному», и сервер может создавать этот ресурс без изменения модели БД.
Вы также можете иметь
ни одна из которых не должна существовать как модель в вашей базе данных или доменном пространстве.
Широко распространено заблуждение, что это неправильная вещь, потому что фреймворки, подобные Rails, учили людей отображать ресурсы способом 1-к-1 для моделей в доменном пространстве, которые снова отображают 1-к-1 со строками базы данных. Это не обязательно и не рекомендуется.
Ресурсы должны быть многочисленными, дешевыми и легкими . Их должно быть легко создать, и они должны быть абстрагированы от вашей доменной модели. Если вы обнаружите, что вам нужен новый, просто создайте новый. Если у вас есть проблемы с этим, то это ошибка вашего фреймворка, а не ошибка REST.
Теперь большое предостережение в том, что ваша инфраструктура позволяет вам это делать. Такие фреймворки, как Rails и Django, которые взяли курс на карту 1-к-1, чтобы «сэкономить ваше время», затрудняют это. Но это недостаток фреймворков, а не дизайна RESTful.
Вот Джим Уэббер, обсуждающий это более подробно (включая несколько раскопок в Rails!)
https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047
источник