Нужен совет по API веб-службы?

Question

В моей компании есть продукт, который, как мне кажется, может получить выгоду от API веб-службы.Мы используем MSMQ для маршрутизации сообщений туда и обратно через бэкэнд-систему.В настоящее время мы создаем приложение ASP.Net, которое взаимодействует с веб-службой (WCF), которая, в свою очередь, общается с нами за MSMQ.Позже в будущем у нас могут появиться другие клиентские приложения (не обязательно написанные на .Net).Сообщение, поступающее в MSMQ, является объектом, свойство которого состоит из массива строк.Существует также свойство, которое содержит команду (строку), которая будет направлена ​​через систему.Лично я не большой поклонник этого, но мне сказали, что это для масштабируемости, и каждая система может использовать строки.

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

Для нашей группы было рекомендовано поддерживать «единую точку входа» в систему, предлагая объект, содержащий команды и один веб-сервис, который позаботится обо всем.Итак, у веб-службы будет один метод, назовем его MakeRequest, и он вернет объект (сериализованный XML или JSON).Было предложено иметь базовый объект, который может содержать какой-то список команд, которые могут наследовать другие объекты.Любой другой объект может иметь свою собственную структуру команд, но все же наследовать базовые команды.То, что передается обратно из сервиса, сейчас неясно, но это может быть тот «объект сообщения» с прикрепленным к нему объектом, представляющим данные.Я не знаю.

Я рекомендовал смоделировать наши объекты после наших реальных данных и создать службы для типов данных, с которыми мы работаем.Мы создадим базовый интерфейс службы, который будет содержать любые общие методы, используемые для всех служб.Так, например, GetById, GetByName, GetAll, Save и т. Д. Для этой конкретной реализации будет реализовано все, что специфично для данной службы.Таким образом, служба пользователя может иметь метод GetUserByUsernameAndPassword, но, поскольку она реализует базовый интерфейс, она также будет содержать «базовые» методы.У нас будет несколько методов в сервисе, которые будут возвращать ожидаемый тип объекта в зависимости от вызываемого сервиса.Мы могли бы разместить все в одном сервисе, но я все еще хотел бы получить что-то более удобное.Я чувствую, что такой подход не позволяет клиенту принимать решения о том, какие команды следует передавать.Когда я подключаюсь к сервису User и вызываю метод GetById (int id), я ожидаю получить обратно объект User.

Я имел возможность работать с MS, когда начал разрабатывать сервисы WCF.Итак, у меня есть хорошая основа и понимание технологии, но я не тот, кто ее разрабатывает в этот раз.Таким образом, я не против идеи «единой точки входа», но любые мысли о том, почему один подход является более масштабируемым, чем другой, будут оценены.Я никогда раньше не работал с таким систематическим подходом к уровню обслуживания.Может, мне нужно преодолеть это?

Answer 1

Я думаю, что у обоих подходов есть свои преимущества.

Как правило, если вы пишете API, который будет использоваться совершенно отдельной группой разработчиков (возможно, в другой компании), то вам нужноAPI должен быть как можно более понятным и доступным для обнаружения.Имея определенные методы веб-служб, которые возвращают определенные объекты, гораздо проще работать с точки зрения потребителя.

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

Мое личное предпочтение - конкретный API.Я думаю, что с конкретными методами гораздо проще работать - и они в основном самодокументированы.Определенная операция должна быть выполнена в какой-то момент, так почему бы не выставить ее такой, какая она есть?Вы бы посмеялись, если бы написали:

public void MyApiMethod(string operationToPerform, params object[] args)
{
    switch(operationToPerform)
    {
        case "InsertCustomer":
            InsertCustomer(args);
            break;
        case "UpdateCustomer":
            UpdateCustomer(args);
            break;
        ...
        case "Juggle5BallsAtOnce":
            Juggle5BallsAtOnce(args);
            break;
    }
}

Так зачем это делать с веб-сервисом?Было бы намного лучше иметь:

public void InsertCustomer(Customer customer)
{
    ...
}

public void UpdateCustomer(Customer customer)
{
    ...
}

...

public void Juggle5BallsAtOnce(bool useApplesAndEatThemConcurrently)
{
    ...
}