HTTP is the protocol that powers the Web. It was originally designed in 1996 for transferring and manipulating simple text-based documents (mainly hypertext resources).
Nowadays it’s been adopted for many different purposes. It’s used for: multimedia content transfer, rich real-time session-based web applications, API messages dispatch, Internet of Things and much more.
For this reason, the HTTP specifications are continuously updated, by adding new features and improving performance.
In May 2015, the latest version 2.0 was standardized with RFC 7540.
This introduced major differences on how the low-level protocol works.
From the application perspective, very little has changed: requests, responses, resources, headers and HTTP methods are still there.
New features have been added such as the possibility to push resources to the client.
As you may have noticed, we went through a bit of a restyling in the last few days, and our blog changed a lot in terms of appearance and structure.
We are very happy with those changes, but the reason behind this transition is not just a simple template change.
What we were searching for
Before, we were using an hosted CMS to run the blog, Ghost. We were happy with the results, it wasn’t our concern to administrate the server or bother about other hosting stuff.
The third edition of Droidcon IT was, as expected, a great conference, full of interesting talks and people coming from all over the world. We saw a lot of GDEs (Google Developer Expert) and also some Developer Advocates from Google, although it was not organized directly by the company. Back in March the Android team surprisingly released the brand new N Developer Preview earlier than expected, so this year we were already able to talk about the new features in Android N and analyze them. Furthermore, there was talk of Kotlin, RxJava and a lot of other useful and interesting topics.
When I started my study about JWT, I was searching for a smart method to authenticate a request, without querying the database each time to check the applicant reliability.
I needed a token or something similar with the ability to validate itself and flexible enough to customize the validation strategy.
Imagine for example a web application where a user can login and obtain a “pass” with his name and an expiration time, and this pass will let him ask for resources until the pass expires, and only if the issuer is trusted.
Thanks to JWT’s self verification capabilities, I could discard every request where the token is invalid (a fake token not signed by my application) or expired.
Beyond this specific use case, JWT can be also useful to securely transmit data to other applications.
Share this post
X
Facebook
Reddit
LinkedIn
StumbleUpon
Pinterest
Email