Nimble GeckoBlog of an upside-down developer, Art Skvira

In today’s world of interconnected apps & services, you may often need to call another API to get or modify information.

In this article I’d like to show you how to do the following:

• call another API in a reliable fashion
• receive and parse the result so that your app can work with it
• display the result on a web page

Let’s get on with it!

More often than not your application needs to have access to various sensitive information, such as logins & passwords of various sorts (database, network resources etc), API keys, encryption keys and alike.

In one of my earlier articles, I demonstrated how that information can be stored in an encrypted way in the application config file – see How to store login details securely in the application config file. This approach, however, is not fool-proof. In fact, it’s quite easy to decrypt the information stored in such a way, provided the attacker has access to the executable with the decryption key.

In this article, I would like to show you a much more secure way of storing and accessing sensitive information – such as usernames and passwords, encryption keys, API keys etc. This method will come particularly handy if you already rely on AWS for some of your application needs.

Web and app development is exciting – you probably tried that and got hooked, and who wouldn’t? Write some code and bam! – see the result immediately. Feels amazing, we all know that.

Naturally, a lot of aspiring devs wonder: wait, can I actually do what I love AND get paid for doing it? Can I become “a real developer” —- one that actually stands a chance of getting an interview & landing a job? Or maybe I need to take an expensive bootcamp or a course to just get started? Even worse, maybe I have to get a CS or Engineering degree to be even considered for a dev role?

This may feel like a massive hurdle, and even more so if your formal education isn’t specifically technical. But is there really just one way? Should you even bother trying to get a foot in the door with no formal credentials?

Handling of URLs and URL parameters in ASP.NET Core is done via Routing Middleware. That’s what Microsoft wants you to believe: Routes in ASP.NET Core provide capabilities of directing incoming requests to route handlers (controllers).

What MS is not telling you, is that Routing also provides copious amounts of reasons to hate it. If you ever said to yourself anything like “OK cool, so I’ll just add a new route for this endpoint, and in no time will go back to the actual task at hand” and then THREE hours down the track when nothing works and your manager is, like, “Have you done it yet?”, you really starting questioning whether this whole web developer career thing is going to work out for you.

As a developer, more often than not you have to deal with other people’s code. And (hopefully only sometimes) you want to throw it all away and rewrite if from scratch. Those of us that are saner (or perhaps just with more battle scars) just roll up our sleeves and get into refactoring. And perhaps you know how awesome it feels to separate someone’s mess of a code into a neatly structured ensemble of classes and corresponding methods, especially when you realise that mess was written by your very self.

When it comes to something as new and quickly changing as .NET Core, and all the other tech that runs on top of it, such as ASP.NET Core and Entity Framework Core, it can be quite daunting trying to keep up with all the changes that Microsoft keeps introducing after finding a seemingly sane and workable solution.

We are naturally drawn towards new stuff - new means better, right? Surely you heard of .NET Core, unless you’ve been living under the rock for the last couple of years. New is hard to resist, especially when it’s backed by Microsoft’s huge PR/propaganda machine. Don’t get me wrong, I am not blaming Microsoft - they’ve got to make sure they attract and retain enough people onto the new platform, but this is exactly the moment you want to stop and ask yourself - what’s better for me, given my task, needs, and constraints?

It is very common in our day and age of interconnected integratedness for an application to be reaching out to external services such as email servers, databases etc. This creates a problem – you need to store usernames, passwords, access codes, API keys etc somewhere and mitigate the risks of that sensitive information either not being found or read by a wrong person.

As highlighted previously in one of those articles, it’s easy to get confused and stuck when trying to specify selected or default value for dropdown lists. The problem stems from the fact that, first and foremost, MSDN documentation is terrible for those things, and secondly because of the approach that Microsoft took, trying to build “one-size-fits-all” solution. But let’s not get too philosophical here and get down to the ground.

.NET Core RC2 has been released just recently and while things have somewhat stabilised, there’s still a lot of confusion around the differences between spanking new .NET Core and the older but more stable .NET Framework.