хорошая практика: REST API как интерфейс между интерфейсным уровнем и бизнес-уровнем?

Question

Я думал об архитектуре веб-приложения, которое планирую создать, и обнаружил, что много думаю об основной части приложения. Поскольку я захочу создать, например, приложение для Android, чтобы получить к нему доступ, я уже думал о наличии API.

Учитывая тот факт, что я хочу иметь внешний API для своего приложения с первого дня, будет ли хорошей идеей использовать этот API в качестве интерфейса между интерфейсным уровнем (веб) и бизнес-уровнем моего приложения? Это означает, что даже основной интерфейс моего приложения будет получать доступ к данным через API. Каковы недостатки этого подхода? производительность

В более общих чертах, если вы создаете веб-приложение, к которому, вероятно, потребуется доступ по-разному, это хороший архитектурный проект, чтобы иметь API (веб-сервис) в качестве интерфейса между интерфейсом слой и бизнес уровень ? Является ли REST хорошим «инструментом» для этого?

Answer 1

Похоже, у вас есть два вопроса, поэтому мой ответ состоит из двух частей.

Во-первых, следует ли использовать API между уровнем интерфейса и бизнес-уровнем?Это, безусловно, правильный подход, который я использую в своем текущем проекте, но вам придется самим выбирать преимущества, потому что только вы знаете свой проект.Возможно, самый большой фактор, который следует учитывать, - будет ли достаточно разных клиентов, обращающихся к бизнес-уровню, чтобы оправдать дополнительные усилия по разработке API?Зачастую это просто означает более одного клиента, поскольку преимущества наличия API будут очевидны, когда вы начнете выпускать изменения или исправления ошибок.Также учтите дополнительную сложность, дополнительные затраты на сопровождение кода и любые преимущества, которые могут возникнуть при разделении интерфейса и бизнес-уровней, такие как повышение тестируемости.

Во-вторых, если вы реализуете API, следует ли использовать REST?REST - это архитектура, которая говорит как о том, как разрабатывается остальная часть вашего приложения, так и об API.Нет смысла определять ресурсы на уровне API, которые не переводятся на бизнес-уровень.Отдых, как правило, является хорошим подходом, когда вы хотите, чтобы многие люди могли разрабатывать на основе вашего API (например, NetFlix).В моем текущем проекте мы выбрали XML поверх HTTP, потому что нам не нужны преимущества, которые обычно предлагает Rest (или SOAP в этом отношении).

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

Крис

Answer 2

Вам определенно понадобится слой веб-службы, если вы собираетесь получать к нему доступ через нативный клиент через Интернет.

Очевидно, что есть много подходов и решений для достижения этой цели, однако я считаю, что правильное архитектурное руководство, которому нужно следовать, - это иметь четко определенный Сервисный интерфейс на Сервере, к которому обращается Шлюз на клиенте. Затем вы будете использовать POCO DTO (обычный старый DTO) для связи между конечными точками. Основная цель DTO состоит в том, чтобы обеспечить оптимальное представление вашего веб-сервиса по проводам, а также позволяет вам избежать необходимости иметь дело с сериализацией, поскольку она должна прозрачно обрабатываться библиотеками Client Gateway и Service Interface.

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

REST - это архитектурный шаблон, который для небольших проектов я считаю дополнительными накладными расходами / сложностью, поскольку он не настолько хорош для программирования, как веб-сервисы RPC / Document Centric. Кратко говоря, общая идея REST - развить ваши сервисы вокруг ресурсов . Эти ресурсы могут иметь несколько представлений, которые должна предоставлять ваша веб-служба, в зависимости от предпочтительного типа контента, указанного вашим HTTP-клиентом (т. Е. В заголовке HTTP ACCEPT). Канонические URL-адреса для ваших веб-сервисов также должны быть логически сформированы (например, / customer / reports / 1 в отличие от / GetCustomerReports? Id = 1), и ваши веб-сервисы в идеале должны возвращать список «допустимых состояний, в которые ваш клиент может войти» с каждым ответ. По сути, REST - это хороший подход, способствующий слабосвязанной архитектуре и повторному использованию, однако он требует больше усилий, чтобы «придерживаться», чем стандартные веб-сервисы на основе RPC / Document, преимущества которых вряд ли будут видны в небольших проектах.

Если вы все еще оцениваете, какую технологию веб-службы вам следует использовать, вы можете рассмотреть возможность использования моей веб-платформы с открытым исходным кодом , поскольку она оптимизирована для этой задачи. DTO, которые вы используете для определения интерфейса веб-сервисов, могут быть повторно использованы на клиенте (что обычно не так), чтобы предоставить строго типизированный интерфейс, где вся сериализация выполняется за вас. Это также дает дополнительное преимущество, заключающееся в том, что каждый создаваемый вами веб-сервис автоматически вызывается веб-сервисами SOAP 1.1 / 1.2, XML и JSON без какой-либо дополнительной настройки, поэтому вы можете выбрать наиболее оптимальную конечную точку для каждого клиентского сценария, то есть Native Desktop или Веб-приложение и т. Д.

Answer 3

Мое последнее предпочтение, основанное на J2EE6, заключается в реализации бизнес-логики в сессионных компонентах, а затем при необходимости добавлении веб-служб SOAP и RESTful.Очень просто добавить клей для реализации веб-сервисов вокруг этих сессионных компонентов.Таким образом, я могу предоставить услугу, наиболее подходящую для конкретного пользовательского приложения.

Answer 4

Нам повезло, делая что-то подобное в проекте.Наши веб-службы в основном выполняют стандартное управление контентом с высокой долей операций чтения (GET) и записи (PUT, POST, DELETE).Так что если ваш логический уровень похож, это очень разумный подход для рассмотрения.

В одном случае у нас есть приложение для видеоплеера на Android (Motorola Droid, Droid 2, Droid X, ...), котороеподдерживается набором веб-сервисов REST в облаке.Они предоставляют каталог видео по запросу, позволяют устанавливать и отключать видеосеансы, обрабатывать закладки и т. Д.REST отлично сработал для этого.

Для нас одним из ключевых преимуществ REST является масштабируемость: поскольку ответы RESTful GET могут кэшироваться в инфраструктуре HTTP, гораздо большее количество клиентов может обслуживаться из одного и того же веб-приложения.

Но REST, похоже, не очень подходит для некоторых видов бизнес-логики.Например, в одном случае я включил ежедневную операцию обслуживания в API веб-службы.Не было очевидно, какой глагол использовать, поскольку эта операция считывала данные из удаленного источника, использовала ее для создания и обновления локальной базы данных, затем удаляла старые данные, затем уходила и сообщала внешней системеделать вещи.Поэтому я решил сделать это POST, сделав эту часть API не RESTful.Тем не менее, имея слой веб-сервисов поверх этой операции, мы можем запускать ежедневный скрипт по таймеру, запускать его в ответ на какое-то внешнее событие и / или запускать как часть рабочего процесса более высокого уровня.

Поскольку вы используете Android, взгляните на Java Restlet Framework .Существует версия Restlet , поддерживающая Android .Несколько лет назад мне рассказывал об этом инженерный директор Overstock.com, и все, что он нам рассказал, было правдой, это феноменально хорошо сделанная структура, которая облегчает жизнь.

Answer 5

Конечно, REST может быть использован для этого.Но сначала спросите себя, имеет ли это смысл?REST - инструмент, подобный любому другому, и хотя он и хорош, он не всегда лучший молоток для каждого гвоздя.Преимущество создания этого интерфейса RESTful заключается в том, что, IMO, в будущем будет проще создавать другие применения для этих данных - возможно, то, о чем вы еще не думали.Если вы решите использовать REST API, ваш следующий вопрос: на каком языке он будет говорить?Я обнаружил, что AtomPub - это отличный способ для обмена процессами / приложениями информации - и он очень расширяемый, так что вы можете добавлять множество пользовательских метаданных и все же быть легко проанализированными с любыми библиотеками Atom.Microsoft использует AtomPub в своей облачной платформе [Azure] для общения между производителями и потребителями данных.Просто мысль.