REST level set - .NET Tutorial

- [Instructor] As this course is about building RESTful APIs, I don't want to rehash or recover the fundamentals of REST, but I do want to level set to make sure we're on the same page about those core concepts. Remember that REST as an architectural design is fundamentally defined by a set of constraints. When you're building your APIs, if you want them to be RESTful, you need to follow these constraints. The first is a client-server architecture. So we're building with ASP.NET, which a server based platform for building web applications and web APIs. And by its very nature, our clients are going to be connecting to that server, and making requests, and receiving responses. Our architecture will be stateless in that we will not require maintaining state between client requests in order to fulfill those later requests. Now we'll obviously store the data. If you're going to save some data, you upload some data, we'll be saving that in the database. And we may also take advantage, and we will, of security tokens when we get into later parts of the course. So there'll be a little bit of state passed back and forth in the terms of those tokens, but that's all acceptable. Cacheability is another one of the constraints. With ASP.NET, we'll see that we'll be able to flag certain operations or certain resource requests as cacheable and identify certain parameters around the cacheability 'cause we want those requests for resources to be able to be cached, not only at the server level to improve the performance on our API and the servers we're using, but also in intermediaries such as proxy servers or other servers in between the client and the server to improve the performance for the client, and take even more load off the server. Layered systems is another one of the constraints. And here, because we're building this as a web API, we're taking advantage of HTTP, we're not going to require that our client and server are directly connected, and it'll allow for having those intermediaries, having those proxy servers or other items, in between the client and server in that layered system that is the web. Code on demand's not something we're going to cover in this course, but it's certainly something that this tool and these patterns that we'll use supports. So we could, for example, if we had a single page application accessing our API, return some JSON back to the client, or some JavaScript back to the client. that they could execute. A uniform interfaces is that constraint that has more constraints. So, we'll look at this one in more detail. Those uniform interfaces, remember, have four additional constraints. The first is that resource identification is in the request, in the URI. We will see in ASP.NET how we can configure and set up what URIs map to particular resources for both requests and operations that are going to update those. We've got a variety of places where we can control that to get the level of detail we need for each resource. Number two is resource manipulation occurs through representations. This means we can pass JSON or XML or other representations of resources, both in requests, and responses, in order to manipulate the state on the server. We're going to primarily work with JSON, but we'll also have the opportunity to configure for XML if for some reason we had clients that needed to negotiate a different representation. Self-descriptive messages are handled, as we'll see, by providing support for different HTTP headers. We have the Accept header. That's very common if you're making a request to get back a resource, identifying what kind of resource representation you'd like or you can support. And we'll have other HTP headers we can use around those messages to add additional descriptive terms. And we'll look at hypermedia as the engine of application state. This is all about making your API discoverable and navigable by clients. So, we'll see at a top level how we can provide a landing page or starting point for our API where clients can come in and understand all the different resources and the URIs to get to them. And we'll also augment some of our resources as an example of how to provide additional linking and navigation from one resource to another, and help the client understand what's available and how to access it.