В какой слой вы кладете свой REST API?

Question

Наше приложение структурировано примерно так:

UI <-> REST API <-> Рабочий процесс <-> Бизнес-логика <-> DAL <-> DB

Однако я вижу несколько примеров, когда люди, похоже, делают

Пользовательский интерфейс <-> Рабочий процесс <-> API REST <-> Бизнес-логика <-> DAL <-> БД

Это мое воображение? Или второй вариант считается жизнеспособной альтернативой?

Answer 1

Это действительно относительно того, что вы имеете в виду рабочий процесс.

Гипермедиа как движок состояния приложения предоставит вам ориентированный граф состояний / ресурсов. Нет необходимости, чтобы эти графики формировали рабочий процесс (например, имели конкретную начальную и конечную точку). Они вполне могут образовывать цикл, иметь двунаправленные связи и еще много чего. Я предполагаю, что этот график каким-то образом получен из бизнес-логики.

Если вы включаете ваш рабочий процесс (конкретный путь от одной точки к другой через график) в своем пользовательском интерфейсе, вы делаете некоторые предположения относительно REST API, поэтому тесно связываете свой пользовательский интерфейс с бизнес-логикой, что исключает возможность обнаружения REST .

В общем случае смешивание рабочих процессов (императивное программирование) с REST (декларативное программирование) очень проблематично. Наилучшим подходом было бы иметь адаптивный пользовательский интерфейс, который может позволить пользователю перемещаться по сети состояний, а не ограничивать их с помощью заданных, заранее определенных рабочих процессов. Так работает браузер.

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

Эти мнения являются моими собственными, однако хорошую, уместную статью по теме можно найти здесь: http://www.infoq.com/articles/webber-rest-workflow

Answer 2

Я только сейчас знакомлюсь с тем, чем на самом деле является ReST, и, надеюсь, я не слишком далеко от базы, но, насколько я понимаю, клиент должен нести ответственность за выбор, в какие состояния переходить (рабочий процесс), так что да, я думаю, что № 2 определенно действителен. На самом деле мне было бы интересно узнать, как вы реализуете рабочий процесс в своем ReST API.

Answer 3

REST - это доступ к ресурсам. Вопрос в том, что такое ресурс? Большинство ответов таковы, что это довольно низкоуровневая информация.

Составное приложение или рабочий процесс зависит от одного или нескольких ресурсов.

Трудно сказать, что ресурс зависит от рабочего процесса. Не возможно. Но тяжело.

При разработке интерфейса RESTful у вас есть только доступные правила CRUD. Наиболее распространенным ожиданием является то, что ответ полностью состоит в браке по вашему запросу. Когда вы POST X, вы ожидаете, что единственное изменение состояния заключается в создании нового X. Не создавать X и Y с необязательной парой Z.

Я бы предложил, чтобы ваша вторая альтернатива поместила REST в лучший контекст - доступ к объектам с состоянием.