Leveraging on WResources
I continued to move all storage related actions to the back-end. The idea is to have a clear separation of front-end (consisting of widgets and callbacks) and back-end (handling of requests). When a complete model is built, the building blocks can be easily replicated and altered to cater for other services. Troubleshooting becomes a breeze too when things are built in an orderly fashion.
Exploiting the refresh_token
Since the discovery of the refresh_token, things are working out great. You can use it whenever you please to exchange for access_tokens, heck, even before every request made to the endpoints. And that’s what the application is doing now. The response is only roughly 200 bytes. There’s even no need to bother about the token expiry. It’s almost feels like an overkill.
Localhost and 127.0.01
There are some confusion I have with these two addresses. All these while I thought they meant the same thing. When hosting the project with 127.0.0.1, I could access it all the same using ‘localhost’ and vice versa. However, when I tried to ‘curl’ localhost when the address is at 127.0.0.1, weird things start to happen. I found out about this because in some parts I used WEnvironment to get information of the server.
and if somehow hostName() resolves to localhost, bad things will happen.