Является ли реализация CRUD Layer на основе HTTP, XML хорошей идеей?

Question

Я делаю «слой» CRUD для приложения. Это будет простое приложение CRUD, которое, например, хранит информацию о пользователе, избранные ссылки и т. Д., А также не выполняет операции с данными «фактического типа». На самом деле, это только для хранения вещей, таких как «Пользователи», «Разрешения», «Правила», «Политики» и т. Д., Которые другие части приложения подходят для выполнения работы.

В целом, я хочу три вещи из этих усилий:

• (а) Единая точка входа для доступа к функциям CRUD
• (б) Возможность использовать любой «клиент», чтобы использовать CRUD слой
• (c) «Легкая» расширяемость CRUD, где может быть добавлен новый объект, и старые объекты могут быть изменены (новые поля добавлены, ничего больше не удалены или не изменены). Типичный сценарий CRUD?

Я думаю, что я должен сделать библиотеку Java, подвергать его клиентам через "REST-типа-URL" (смысл только в REST-URL-пути, как "пользователей/удалить/2") API через HTTP. Таким образом, я могу встретить все 3 цели - уровень CRUD может быть на Linux, клиент может находиться в Windows.

В слое CRUD я буду использовать различные вещи, чтобы это произошло: ORM, веб-сервер и другие инструменты.

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

Является ли то, что я думаю о том, чтобы сделать чрезмерно упрощенное представление о наборе методов API в XML-фрагмент? (обратите внимание, что я не делаю XML-RPC, скорее эти XML-фрагменты будут представлять собой только данные - и XML будет отправлен на определенные URL-адреса, такие как users/update/2, которые будут обрабатывать XML после подтверждения того, что XML содержит информацию для профиля пользователя)

Я в порядке? Имеет ли эта идея даже отдаленный шанс работать?

Любая помощь оценена!

Answer 1

Да, это сработает. Тем не менее, вы основываете свой дизайн распределенной системы на предположении, что модель данных очень проста и останется таковой. Если созданное вами приложение успешно, вы можете быть уверены, что будут добавлены новые требования и будут запрашиваться новые функции.

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

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

Редактировать, чтобы ответить на вопрос в комментариях о клиенте нуждающегося понять модель:

У вас есть два различных направления вы можете предпринять относительно того, как клиент может взаимодействовать с представлением полученных от сервера.

1. Вы можете разрешить клиенту иметь ясное знание содержимого данных, содержащегося в представлении. То есть Клиент знает, что в некоторых элементах XML есть имя пользователя и пароль. Однако, если вы это сделаете, вы должны вернуть определенный тип носителя, например. Приложение/vnd.mycompany.user + XML. Вы не должны использовать application/xml, так как это не говорит клиенту ничего о том, что есть в документе XML. Если клиент должен был знать, что «когда вы идете по URL-адресу X» вы получаете «документ Xml, который содержит элементы UserName и Password внутри элемента User», то вы нарушили самоописательное ограничение REST. Воздействие заключается в том, что вы связали конечную точку с медиа-типом и фактически связали клиента с этой конечной точкой. Цель «ограничения гипермедиа» REST заключается в предотвращении связи между клиентом и конечными точками.
2. Альтернативой является использование более общего типа носителей, который просто предназначен для предоставления клиенту контента для отображения пользователю и предоставления пользователю возможности для принятия действий. Тип медиатеки html позволяет сделать это, предоставив язык разметки, который можно использовать для возврата имени пользователя и пароля в два тега div. Используя тег HTML и тег html, клиент может выполнять дополнительные операции над этим ресурсом. Выяснив, как сделать доступными все возможные операции, которые может иметь объект «пользователь», по-настоящему RESTful, сложнее и требует довольно много опыта, но конечный результат - очень хорошо развязанный клиент и сервер. Посмотрите на веб-браузер в качестве примера, как часто вам нужно делать обновление браузера, потому что веб-сайт изменил его содержимое.

Проблема с вариантом номер два заключается в том, что использование только HTML-кода, как правило, имеет ограниченный характер, и именно здесь находится Javascript. Одним из «необязательных» ограничений REST является загрузка кода , Javascript - это код, загружаемый с сервера, для обеспечения дополнительного поведения на клиенте. К сожалению, на мой взгляд, это также дает возможность людям создавать веб-интерфейсы RESTful, которые возвращают application/xml, а затем используют javascript для интерпретации этого общего формата. Это решение отлично подходит для оригинального разработчика веб-сайта, который использует RESTful API, потому что, если содержимое xml-файла изменяется, javascript можно изменить и повторно загрузить в браузер, и все хорошо. Тем не менее, для любого другого стороннего разработчика, который обращается к этому API, который не контролирует модель содержимого приложения/xml, их код становится полностью хрупким и потенциально ломается, если изменяется содержимое API. Спросите любого, кто написал какой-либо клиент для Twitter, сколько раз их приложение нарушилось, потому что Twitter изменил контент.

Используя первый вариант и предоставив контент определенному типу мультимедиа, разработчик сервера может представить новый медиа-тип, называемый application/vnd.mycompany.userV2 + xml, и используя согласование контента, существующие клиенты все еще могут получить оригинал тип носителя и новые клиенты могут быть созданы для использования нового типа носителя. URL-адрес остается неизменным, закладки не разбиты, потому что конечная точка и медиатип не связаны.

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

Answer 2

Если вы ищете решение для Java, я предлагаю вам взглянуть на Restlets. Вы в значительной степени смешиваете архитектуру стиля XML-RPC и REST. Here - различия между RPC и REST.
Вы должны использовать URI, чтобы определить действие и параметры вместо передачи XML, если вы хотите сделать это RESTful способом.

Answer 3

Для чистого слоя данных вы подумали о поддержке транзакций?

• Нужно ли поддерживать операции? Если да, то как они будут реализованы?
• Будут ли транзакции охватывать несколько HTTP-запросов? (Я бы подумал, что для чистой реализации REST у вас будет несколько вызовов для нетривиальных операций). дебетовать одну учетную запись и кредит другой учетной записи.
• Кто контролирует транзакции?

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

Больше вопросов, чем ответов. :) Но пища для размышлений.

UPDATE:

Я хотел бы создать стандартный слой доступа к данным, используя язык по выбору (в вашем случае Java), а также любых других библиотек, которые необходимо (например, ORM). Если у вас уже есть дизайн уровня доступа к данным, я бы следил за этим, чтобы приложение было простым. Если вы хотите разоблачить это извне (для разных клиентов), я бы сделал это в том, что я назвал бы сервисом/бизнес-слоем (если функциональность проста, без возможности повторного использования, как для одной реализации, вероятно, будет ОК). Там вы будете обрабатывать любую безопасность (аутентификацию, авторизацию и т. Д.), Проверку данных и потенциально выполнять любое сопоставление между внутренним представлением данных и внешним представлением. Затем вы можете предоставить свои услуги в соответствии с вашим API на основе URL. Это дает вам некоторое разделение между реализацией фактического доступа к данным и вашим интерфейсом.

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

Answer 4

Это хорошая идея, если вы хотите получить доступ к функции CRUD у нескольких клиентов. Некоторое время мы делали что-то подобное. Некоторые детали реализации, которые могут вам помочь.

1. Просто HTTP-звонок достаточно хорош, не беспокойтесь о REST. Чтобы быть RESTful, вы должны следовать правилам (GET для READ, PUT для создания и т. Д.). Просто используйте GET, чтобы его можно было легко протестировать в браузере. Мы используем XSLT для форматирования ответа в таблицах в HTML.

2. Мы используем одну XML-схему для обработки всех ответов. Это в основном XML-представление результатов SQL, которое должно быть достаточно гибким, чтобы обрабатывать множество результирующих наборов, затронутых строк, ответ на ошибку, код возврата и т. Д.

3. Имейте JSON-представление XML, поэтому его легче обрабатывать в Javascript.

4. Мы также добавили SQL-бэкдор, поэтому произвольная инструкция SQL может быть отправлена ​​в базу данных. Это очень удобно для отладки. Для такого вызова необходима определенная безопасность. Мы открываем его только в офисной сети.