REST для разработчиков Java: Часть 4. Будущее за RESTful

  1. REST для разработчиков Java

С точки зрения ИТ-менеджера, REST может быть просто еще одним способом перемещения информации, но без всех инструментов, связанных с SOAP. В этой заключительной статье из серии REST для разработчиков на Java Брайан Слеттен рассказывает об этом мифе и нескольких других о REST, рассматривая его роль в новых архитектурах, таких как семантическая сеть. По его словам, переход к REST - это не отход от SOAP, а охват всей сети как внутри, так и за пределами предприятия.

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

В этой последней статье этой серии я рассмотрю концепции REST как основы для динамических, масштабируемых, ориентированных на ресурсы архитектур. Я покажу, как цели и видение REST соотносятся с более крупными планами для самой сети. Я также объясню, как такие концепции, как HATEOS, описание и обнаружение ресурсов, а также связанные данные уже работают в таких проектах, как проект «Связывание открытых данных», и как они применяются к интеграции корпоративных данных. Наконец, я расскажу о том, как этот общий подход может усилить ваш профиль безопасности, и оставлю вам некоторые идеи по улучшению долговечности ваших интерфейсов RESTful.

Как вы знаете из первая статья В этой серии Рой Филдинг определил REST для описания свойств, возникающих в результате преднамеренного применения определенных архитектурных ограничений. Архитектурный стиль REST основан на идее многоуровневого взаимодействия клиент-сервер без сохранения состояния. Взаимодействие RESTful происходит через унифицированные интерфейсы с поддержкой кэширования и необязательным расширением с помощью кода по требованию, как показано на рисунке 1.

Взаимодействие RESTful происходит через унифицированные интерфейсы с поддержкой кэширования и необязательным расширением с помощью кода по требованию, как показано на рисунке 1

Рисунок 1. Ограничения REST объединяются, чтобы обеспечить гибкую, масштабируемую архитектуру. (Нажмите, чтобы увеличить.)

В качестве еще одного напоминания о том, что такое REST, вот что это не так :

  • Средство для вызова произвольного поведения через URL
  • Вставная замена для SOAP
  • Легко
  • Игрушка

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

Окружающая среда, как NetKernel продвигает согласование содержимого с поздним связыванием на шаг вперед с идеей исполняемой инфраструктуры для поддержки преобразования ресурсов. Напомним, что NetKernel обслуживает информационные ресурсы в различных вариантах, называемых аспектами . Одним из наиболее полезных понятий является способность декларативно конвертировать эти формы. У вас есть XML-документ в качестве аспекта DOM, но что, если вы хотите, чтобы он использовался как узел, отсылаемый для обработки XQuery? NetKernel будет делать это на лету с помощью процесса, называемого transreption (преобразование представления).

REST для разработчиков Java

Серия из четырех частей, написанная Брайаном Слеттеном:

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

Возможность конвертировать данные из представления XML в представленное представление может показаться волшебством, но это не так. Вы испытываете это каждый день в Интернете. Хитрость заключается в том, чтобы сделать следующий шаг и подумать о вашей информации в целом. Тот факт, что один и тот же стиль взаимодействия дает вам свободу связывания с поздним связыванием и согласованием содержания, позволяет создавать гибкие системы, которые масштабируются и могут быть перенесены без прерывания работы клиентов, и это не дает результатов. REST не представляет интереса, потому что он проще и проще, чем SOAP: REST представляет интерес, потому что он решает реальные деловые и технические проблемы, которые преследуют ИТ-индустрию в течение многих лет.

Но как насчет других разработчиков и менеджеров в вашем магазине?
У вас есть XML-документ в качестве аспекта DOM, но что, если вы хотите, чтобы он использовался как узел, отсылаемый для обработки XQuery?