Limit the number of service calls in a RESTful application

Imagine some kind of a banking application, with a screen to create accounts. Each Account has a Currency and a Bank as a property, Currency being a separate class, as well as Bank. The code might look something like this:

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; }
}

According to the REST design principles, each resource in the application should have its own service, and each service should have methods that map nicely to the HTTP verbs. So in our case, we have an AccountService, CurrencyService and BankService.

In the screen for creating an account, we have some UI to select the bank from a list of banks, and to select a currency from a list of currencies. Imagine it is a web application, and those lists are dropdowns. This means that one dropdown is populated from the CurrencyService and one from the Ba开发者_如何学GonkService. What this means is that when we open the screen for creating an account, we need to make two service calls to two different services. If that screen is not by itself on a page, there might be more service calls from the same page, impacting the performance. Is this normal in such an application? If not, how can it be avoided? How can the design be modified without going away from REST?

---

It's an architectural decision that you should base on the size and complexity of your system. The more large/complex your system is, the more it's likely to benefit from increasing levels of separation/encapsulation (for example, you may find that BankService needs to scale more aggressively than CurrencyService, and running these services separately will allow you to do that).

What I would point out in response to your question, though, is that you should be considering caching the results of these service calls and reusing the result, rather than re-calling the service for every page load. If (as the names would suggest) the result of CurrencyService and BankService are not likely to change very often, you could cache them for minutes or hours at a time and not have to repeatedly make those calls.

If your application is busy (that is, if you think in terms of hits-per-second rather than hits-per-hour) then this can save you memory at runtime since the result of a single service call is shared between multiple page requests (rather than each page needing to get the result set separately).

---

it is normal and can not be avoided... ...unless you create a specific service that returns all the data for a specific screen in one run.

This is one of the negatives of the REST approach - basically if you deal with object queries, and you need lists of x objects, then you have x calls. Point.

Which means REST designs have limited scalabilit on that level.

Again, as in the start - you can always have a specific service returning all data you need on a complex form in one call.

---

Hang on, ReST is about representing resources.

I don't think you should be too strict on the following:

According to the REST design principles, each resource in the application should have its own service, and each service should have methods that map nicely to the HTTP verbs.

It should be perfectly fine that the resource your representing in the browser is a "form" and contains all the relevant information.

Just think about the right degree of abstraction when defining your URL structure.

---

Slavo,

there is no need to provide different services for different resources. In general, you should simply provide the views that help your clients achieve their goals. If one of such views is an integrated 'big' view (resource) including all the banks and currencies then that is fine. You still can provide fine grained views (resources) for authoring and editing banks and currencies.

If the banks and currencies happen to be provided by different Web applications and you need the client to resolve the references, then keep in mind that HTML pages do this all the time with inline images. Caching goes a long way to reduce the number of network calls in such scenarios (and the list of banks and currencies seem not to be very volatile).

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

Example:

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>

The sub requests to banklist and currencylist should be served from the client's private cache most of the times.

Jan