Prashant Padmanabhan [Prashant Padmanabhan] - Java Ee 8 and Angular

• Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals

• Improve your learning with Skill Plans built especially for you

• Get a free eBook or video every month

• Mapt is fully searchable

• Copy and paste, print, and bookmark content

Security concepts go beyond frameworks and applications in general. There are various strategies employed to secure both the frontend and backend. Solutions can range from OAuth to JSON Web Tokens (JWT) and more. As of now, our backend service doesn't have a security mechanism in place. We will look at security, which is better covered in the chapter aptly titled Securing the application.

There are identity platforms that can be leveraged to build security for our application. One such platform is Auth0, which solves identity use cases. The single-page application can follow an OAuth based-flow or use JWT token-based authentication for its authentication and authorization needs.

For our backend project, we will be using JWT for backend/API validation and for the frontend app we will store the issued token and pass it during each HTTP call. In this chapter, we will not be using any login/authentication features as that will only complicate the setup to begin with. Once we have a working model, we will expand and add the security layers for completeness. Nevertheless, in our case we do need a user to simulate the flow, which we can add by having it defined as a dummy data.

We define an AuthService in the application, which will return the current user. This, for this chapter's purpose, will be a dummy account that is returned. The sample service is shown here, and will later get replaced by an actual implementation:

For the majority of developers, this may not impact the way you write servlet code, but it does offer some performance benefits along with new abilities such as server push. HTTP/2.0 is a binary protocol based on frames and is the new standard for the web. HTTP/2 standard was approved around February 2015 and is supported by most modern day browsers. While the web has been evolving at a fast pace, the same can't be said about HTTP itself. For years, developers had to work around the limitations of HTTP 1.x, but the wait is finally over, as this version has better alignment with modern day demands. Some of the HTTP/2 benefits include the ability to reuse the same TCP connection for multiple requests, more compressed header information, priority and packet streaming, and server push to send resources from the server to the client. This results in reduced latency with faster content downloads. For the uninformed, this change won't be a crucial change and your applications will continue to function as they did before with the added benefit of faster performance.

So, there are no new HTTP methods and no new headers or URL changes that you need to worry about. Since Java EE servlets are primarily based on the HTTP protocol, it was only logical for it to get updated to meet the changes in the HTTP standards. The 4.0 update is mainly focused on adding support for the HTTP/2.0 standard, and thus is a 100% compliant implementation for the HTTP/2 specification. What this update should bring with it is increased performance.

Some of the features of HTTP/2 are:

• Request/response multiplexing (bi-directional support)
• Optimized headers (uses HPACK header compression)
• Binary frames (this solves the HOL blocking problem present in HTTP/1.1)
• Server Push
• Stream prioritization
• Upgrade from HTTP/1.0

Servlet 4.0 serves as an abstraction of the underlying protocol, allowing us to focus on the high-level APIs that shield us from the intricacies of HTTP. It's also interesting to note that the servlet specification itself is relied upon by other specs, such as JSF, which will be utilizing these updates to their benefit. Typically, you can think of an HTTP request/response cycle as one request and one response, but that just changed. Now one request can be used to send out multiple responses. To put this into perspective, remember the earlier workarounds of HTTP 1.1, such as domain sharding or where we tried to save multiple requests in order to reduce the TCP connection overhead, such as using CSS Sprites (one image combined with multiple images), well thats no longer needed.