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

Question

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

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?

Answer 1

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

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

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

Answer 2

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

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

Что означает, что дизайн REST имеет ограниченный коэффициент масштабирования на этом уровне.

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

Answer 3

Hang on, ReST - это представление ресурсов.

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

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

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

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

Answer 4

славяно,

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

Если банки и валюты оказываются различными веб-приложениями, и вам необходимо, чтобы клиент разрешил ссылки, помните, что 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> 

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

Jan