Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
A Quick Note
The HATEOAS in this repository does not follow any “standard” like HAL, for example. But it is enough that you get the idea and an impression how to use it.
I just played around a little bit and maybe you can get some inspiration of how to get stuff going with that in your project. This is only one approach. I would love to hear yours in the comments.
HATEOAS stands for hypermedia as the engine of application state. Through the separation of client and server, HATEOAS provides the ability for both sides to grow and evolving separately. With HATEOAS, the server not only exposes the resource that the client asked for, but also the links that tell how to navigate through the application. There is no standard for HATEOAS out there yet (maybe someday there will be) but different ways to do HATEOAS do exist. One of them is HAL, but there is also JSON-LD, etc. A nice blog post which discusses all the different approaches can be found in the links at the end of this article.
The backend is an ASP.NET Core Web API, which provides data using JSON. Every HTTP response contains the specific links and also all the links containing the paging links to the next page, previous page, etc.
So if we now start the WebAPI with dotnet run and fire a request to the endpoint http://localhost:5000/api/customers/ we get the following result.
Because of the QueryParameters we can also fire a request like this,http://localhost:5000/api/customers?pagecount=10&page=1&orderby=Name, and we can get paging going on over the link there.
The front-end application is implemented using AngularCLI and Angular Material. The SPA application has 3 modules:
core- Provides the base services to the application.
customer- Has all customer related components such as the list and the details.
app- The application module.
You can take a closer look at these in the repository I have linked to at the end of the article.
The Data Services
The coremodule is implementing the data services to ensure the communication with the ASP.NET Core WebAPI.
The HttpBaseService abstracts the HTTP requests for the application. The interesting part is that the update and delete methods are getting the complete URL passed as a parameter. This will be explained later. The addmethod is doing a post to the same URL as the getAll function.
The URL part before the customer/ can be extracted in a seperate service if you want. This would come from the environment you are running on later.
The specific CustomerDataService then exposes only one method by extending the HttpBaseService. It switches around the method type which gets passed as a parameter for the corresponding method, like doing an update (PUT), an add (ADD) or a delete (DELETE).
To use this in a component, only the fireRequest method with the correct HTTP verb needs to be called:
Or to get all customers in this case:
So, you can see that for the update, add and delete methods, only one method with the correct HTTP verb has to be called. The URL comes from the entity (customer in this case) itself which gets served over the endpoint coming with its links.
I hope this gives you some inspiration for what you can do with Angular and ASP.NET Core. If you made it this far, thanks for reading!