Ограничьте количество вызовов службы в приложении RESTful - PullRequest
Новая
       13

Ограничьте количество вызовов службы в приложении RESTful

1 голос
/ 09 марта 2010

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

public class Account
{
    public Currency Currency { get; set; }
    public Bank Bank { get; set; }
}

public class Currency
{
    public string Code { get; set; }
    public string Name { get; set; }
}

public class Bank
{
    public string Name { get; set; }
    public string Country { get; set; }
}

В соответствии с принципами разработки REST каждый ресурс в приложении должен иметь свой собственный сервис, и у каждого сервиса должны быть методы, которые хорошо отображаются на глаголы HTTP. Так что в нашем случае у нас есть AccountService , CurrencyService и BankService .

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

Ответы [ 4 ]

2 голосов
/ 09 марта 2010

Это архитектурное решение, которое вы должны основывать на размерах и сложности вашей системы. Чем крупнее / сложнее ваша система, тем больше она может выиграть от повышения уровня разделения / инкапсуляции (например, вы можете обнаружить, что BankService нужно масштабировать более агрессивно, чем CurrencyService, и запуск этих служб отдельно позволит вам сделать это ).

Что я хотел бы отметить в ответ на ваш вопрос, так это то, что вам следует кэшировать результаты этих вызовов службы и повторно использовать результат, а не повторно вызывать службу для каждой страницы. нагрузки. Если (как следует из названия) результаты CurrencyService и BankService вряд ли будут меняться очень часто, вы можете кэшировать их по несколько минут или часов за раз, и вам не придется повторять эти вызовы.

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

2 голосов
/ 09 марта 2010

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

Это один из недостатков подхода REST - в основном, если вы имеете дело с объектными запросами и вам нужны списки x объектов, то у вас есть x вызовов. Точка.

Это означает, что REST-дизайны имеют ограниченную масштабируемость на этом уровне.

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

1 голос
/ 09 марта 2010

Подождите, ReST представляет ресурсы.

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

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

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

Просто подумайте о правильной степени абстракции при определении структуры URL.

0 голосов
/ 09 марта 2010

Славо,

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

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

(см. http://www.nordsc.com/blog/?p=152)

Пример: 


GET /service/account-management

200 Ok
Content-Type: application/vnd.my.accounting
<page>
...
<banklist href="http://other.org/service/banklist" type="application/atom+xml" />
<currencylist href="http://standard.org/currencies" type="application/rss+xml" />
...
</page>

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

Jan

...