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

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

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

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

Ответ 1

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

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

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

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

Крис

Ответ 2

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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