Now we'll look at application architecture. When we're architecting application services applications, we're talking about services. Generically, they're data services. They're things that we apply to objects or resources which are usually things containing data. They're the classic for updates, references, and then there's find, lists, sort, analyze and so on. All these different things we can do through application programming interfaces or through a web service. As we've said before, we're focusing on the services. We'll start by talking about Roy Fielding and RESTful architecture. REST standing for representational state transfer. The whole concept was designed around HTTP, but now it's often being applied to web APIs as well. It has these wonderful features of being flexible, scalable. There's a lot of nice stuff about it. Not everybody uses every bit of REST. Some people use some features, some people use others. Here are the basic principles, the six basic pieces of RESTful architecture. The last two don't tend to be used all the time, but they are ones that we will talk about, rather the first four are the ones we're going to talk about, sorry. The first three I think we've talked about in one way or another all ready. Caching is the notion that you have some kind of process by which you can collect previously acquired results of various types of activities, and then if somebody ask for the same result again, you can go retrieve it from the cache as opposed to making the servers go through the whole process again. There's also one idempotent of a term that basically means repeatable without subsequent state changes. This is not strictly speaking a principle that you see. He doesn't specifically talk about it as being a RESTful property, but it is something that is useful when you're building a system. It's a bit of a robustness feature in that, if you get duplicate requests, the right thing happens. If you read a resource, you always get the same result. If you write the same data twice, you always get the same result. A nice thing about idempotence is that it's easy to model formally too, which basically means it's nice to your brain when you're trying to analyze what the system's doing. HTTP methods and the CRUD API, create, read, update, delete, CRUD. We've got post, get, put, and delete in HTTP that we more or less map to to the CRUD operations. Now, in layering, how do we deal with security in an architecture? That's essentially the question that gets posed at this point. A lot of architectural concepts and frameworks don't talk about security. As Fielding pointed out, it doesn't scale. Fielding basically took what he saw was the critical elements of building effective robust services, and made sure that one of those features was scalability. As a result, since he couldn't come up with a good way of doing, I think the main issue was authentication. He didn't see a good way of scaling authentication in the architecture, so he said okay fine, we'll put a security bubble around the architecture, and then in so far as you need security, it has to be addressed by the bubble, and then once you're inside the bubble, you get the services. The two types of elements that give us our bubble are TLS, SSL, and authenticated sessions. TLS, it's useful. It does provide us that wonderful envelope of crypto protection as the data goes between server and client and back. On the other hand, the client is able to authenticate the server. But TLS, Traditionally, the way people use TLS, it will not authenticate the client. A lot of services support that, but then that means the client needs to have built-in credentials of types that people don't usually have on their browsers these days. TLS is really useful in this, and aside from not being able to authenticate the client, it does an excellent job here. Now remember, we talked about our services as being stateless. The notion being that we go in, we perform an operation, and all the details of the operation are maintained somewhere else. The operation itself doesn't remember where you are in things. The way that works generally, is you save all the information in database entries or possibly in the browser itself, know that has its own issues. What we do is we have sessions in order to address the issue of statelessness. Once you've established a session, the session is what is used to pull together a series of transactions that all belong together, to a particular authenticated individual. We start with authentication, then you establish the session. The session ID serves as an identity token, and once you log out or shut down the session, the session ID is no longer any good.
