I currently plan to publish 8 parts for this series:
- Intro - The one your are reading right now. ;-)
- Web API Server Setup
- Basic Routing
- Cross Origin Resource Sharing
- Token Authentication
- Relational Databases
- Secure Token Service
I still have some topics in my mind for one or two follow ups.
Let’s start with an overview about services and Web APIs.
A typical service
What’s a typical service? A service is something helping you to implement your business use cases. For example, if you need to manage product data, you will have a service, which can read, write, update and delete product data. This functionality can be accessed by a defined interface. This interface can - for example - be a HTTP Web API or real-time WebSockets communication. You model your business use cases into reusable and accessible services which can be consumed by clients - or consumers - speaking your defined interface.
The service itself abstracts away everything behind it. You ask it for information, you get information. No matter if the service itself has to query the file system, a database or another 3rd party system. It will aggregate all necessary information to satisfy your request.
For sure you want every client to be able to access your data leading to the usage of standard protocols instead of proprietary ones. Likely you will end up using some HTTP'ish Web API. It does not matter, if it is a full blown HATEOAS REST Web API or a pure HTTP Web API. It is a whatever API you want it to be. It depends on your use case what suits your business and how clients can access and explore the data you want to expose.
For this blog series we are going to build services based on a HTTP Web API. We'll create URLs which can be used to access our services. By speaking of HTTP all the time it always includes HTTPS, too. In production your services should always be accessible via HTTPS only to use a secured transport method.
The service itself is secured by some authentication mechanism. Most of the time it is a token authentication as described by the OAuth2 or OpenIdConnect protocol.
The diagram shows a high-level overview. The client - for example a browser, a mobile app, a desktop client or your fridge - will first request a token from a Secure Token System (STS). The STS itself is just another service capable of issuing and validating tokens. I assume that we don’t implement this ourselves and use a ready-to-go system like IdentityServer4 for .NET or node-oauth2-server for Node.js.
After getting a token the client requests data from a Web API. The Web API eventually will use other services, storages and third party systems to gather all the data you want to have. Then it sends you back the response. Your client can happily render the data. :-)
For the series we are going to build a Customer Web API which can return a list of customers, create a new and delete an existing customer.
Everything mentioned in the blog series is covered by an open-source GitHub project. In this project you will find a Web API built with Node.js, the same built with ASP.NET Core 1.0 and an Angular 2 Client to query the services. If you don't want to wait for the next post to be published, I highly recommend to take a look at the GitHub repository which is already fully developed.
Read the next blog article about Web API Server Setup.