While that improved support is better than what was there before, it still has a ways to go before being CDN friendly – the real scalability benefit.

Let me just add that you’re unlikely to achieve great performance improvements when using these patterns for private data at the single user level. While you can improve latency on subsequent requests by the same user for the same data (filtering/sorting done browser side), you won’t see the same level of throughput increases as with public data.

Make sense?

On security – yes – had a discussion the other day where the comment was “if the box is owned they could do IL injection or…” If the box is owned you’ve got MUCH bigger problems than IL injection, my friend.

HTTPS is used only to send the key.
At that point, data is sent over plain HTTP.
The data, however, is encrypted server side using that key before being sent over HTTP.
Then the browser decrypts the data using that key.

I don’t think you need to worry about performance problems on the browser – not unless you’re sending large quantities of data.

The question of how secure it is, well, that’s dependent on what assumptions you have of the user’s box. If it’s been root-kitted, all bets are off, regardless of how data gets to the user.

Security is not a boolean thing, it’s cost-benefit tradeoff just like everything else. Create a threat-model and assess solutions against it.

Is that any clearer?

I won’t get into the specifics of banking but if you want to exchange data securely over REST there are ways to do that as well.

One option is to serve sensitive data over HTTPS.

Another, more highly performing, option is to use HTTPS to send a symetric key to the browser which is then used by the client-side javascript to decrypt all data sent.

Does that help?

Since ISPs pay for bandwidth, they cache what they can to save on it. That isn’t all there is to being an intermediary, but still something you can take advantage of.

I did some poking around via Google to try to get a better understanding of who are the actual intermediaries you might have been referring to. I found a bunch of articles on the liabilities of being an intermediary instead. So, I’m still scratching my head a little bit. Perhaps, an article more on the specifics of making use of intermediaries? At any rate, keep writing!

Thanks,
BN

Glad you liked it.
More are coming

The problem that I’ve found when “an organization is adopting SOAP”, is that it is purely technical change. While there may be some value in technical standardization, especially around application integration, no “quantum leaps” will come from it – definitely not IT Business alignment.

Only from asking the business about the semantics of their data and processes, and working with them in refining those models, can intelligent, business viable, technical decisions be made.

At that point, well, the right tool can be used for the right job – be that REST, SOAP, or flat files.

Thanks for all your comments.

This actually has little to do with SOA, which also requires a strong emphasis on the data and how it can be partitioned.

To your question, the intermediary caching is a part of the internet, not intranet.

This reinforces to me why SOA projects often ends up failing, because there is not enough emphasis on the data and how it can be partitioned. It also highlights why REST scales so well – caching and cache validation are built right into the protocol.

Did you add any of your own intermediaries for caching or was the intermediary caching happening as part of existing Intranet infrastructure?

I’ve found that when big numbers are involved, it’s important to get percentages accurate by measuring to understand the exact scope of any impact.

Next, we’re careful not to throw the baby out with the bath water. The business is the one that decides what’s worse, the extra expense of providing 100% of the users with always accurate data, or N users with degraded functionality. I have yet to see a business scaling to this many users choosing accuracy over profitability.

Finally, we look at ways to minimize the degradation of functionality – for instance, by comparing the user’s time zone with that of the location where we the cookie says they are. If there is a discrepancy, we refresh the location based on the current IP. This solves the problem for users travelling between time zones, further decreasing the number of affected users.

Rinse and repeat.

And thank you for your kind words.

The moment you bring in caching (location + weather data) you immediately create potential problems in the user experience – a good example is the “are you not in Londong?” thing that is there to actually solve a user experience problem of a user NOT being where you think he is. There are of course many other potential problems where a solution is not as easy (wrong weather data etc..).

My question is: Since these potential problems are going to affect a very minor set of customers, lets say no more then 0.5% of the customers. However, as you begin with these methods because of scalability issues as you wrote, having 10 million customers or more would mean that at least 50,000 customers would get affected.

How would you weigh the benefit of the added scalability with the “cost” of customer issues for 50,000 unhappy customers or more for which you hurt their experience compared the the tradition “web method” approach?

Thanks – Love your articles –
Ofer

You could do that, but IIS would be a really poor choice for it. Squid would be preferable.

These are the same concepts – absolutely.