RESTfulness SOA с единой точкой входа - PullRequest
Новая
       24

RESTfulness SOA с единой точкой входа

1 голос
/ 26 июля 2011

У меня сервис-ориентированная архитектура с одним шлюзом для всех клиентских запросов.Мне это нравится, потому что шлюз аккуратен, скрывает все «внутренние» службы и выполняет функции диспетчера и самодельного балансировщика нагрузки.

Однако из-за моей конструкции клиент знает только об «одном» ресурсе.И должен отправлять сообщения с запрошенными операциями и их параметрами, определенными в JSON. 

{
    "operation" : "Login",
    "parameters" :
    {
         "username" : "John",
         "password" : "1234"
    }
}

Должен ли я печалиться, потому что моя архитектура не RESTful?Разве я не использую HTTP, как предписывает REST?Пожалуйста, критикуйте.

Ответы [ 2 ]

2 голосов
/ 26 июля 2011

Я не знаю, является ли "грустное" правильным словом, но один из аргументов в пользу REST, особенно когда он реализован в использовании HTTP "правильно", заключается в том, что он предоставляет вам бесплатно следующее (взято из диссертации Филдинга):

  • Клиент-серверное взаимодействие, отделяющее пользовательский интерфейс от хранилища данных
  • Сервер без сохранения состояния, повышающий надежность и масштабируемость
  • Клиентский кэш, уменьшающий сетевой трафик
  • Унифицированный интерфейс, отделяющий реализации от предоставляемых ими сервисов
  • Многоуровневая система, где каждый компонент касается только тех, которые находятся чуть ниже или чуть выше него
  • Ориентация представления, где вы мыслите с точки зрения ресурсов
  • HATEOAS, где ваше приложение по существу перемещается по ссылкам
  • Ограниченный интерфейс с небольшим количеством глаголов (например, GET, PUT, POST, DELETE и только около 3 других)

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

Службы RESTful стали очень популярными и не случайно. Но значит ли это, что у вас есть для создания сервисов RESTful или что сервисы без RESTful по сути намного хуже? Я так не думаю. Я сделал пару RESTful SOA для двух разных компаний, и хотя я предпочитаю SOAP (который кажется громоздким в наши дни) и доморощенные API-интерфейсы, подобные вашему (которые, хотя и элегантные, не являются стандартными), я не Рассеять другие подходы и отклонить их как низшие.

Если вы собираетесь использовать свой собственный API и возвращать только 200 и 404, и делать все с помощью GET, то да, ваш API концептуально прост и, возможно, он будет работать нормально для вас. Но если вам нужны разнообразные типы носителей и у вас есть постоянные требования к хранилищу, содержащие коллекции, которые часто добавляются, удаляются, создаются и обновляются, то изучение современного дизайна RESTful API по крайней мере откроет для вас новые способы мышления.

Суть в том, что вам не нужно ни грустить, ни чувствовать, что вам нужно идти в ОТДЫХ, потому что это делают все остальные. Но преимущества реальны, и REST - это не просто реклама.

1 голос
/ 26 июля 2011

Неа.По сути, у вас есть RPC в стиле SOAP домашнего приготовления, использующий JSON вместо XML.

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

В остальном, мне кажется, что это нормально.

...