Sometimes there is an urgent need popping up in the middle of an investigation of what is happening with your application server – e.g., a process is showing up, but refuses to serve network connections. There could be thousands of reasons why it is stuck, but one of the most common and a classic problem is deadlocked threads, i.e. threads that didn't share some of the resources on start-up correctly.
On one of my recent projects I’ve been asked to describe how our Restful API can be consumed by a third party service. In a SOAP world this task usually boils down to providing a WSDL, which can simplify understanding of exposed API, and can also be used for generating API clients in a most standardized manner.
It seems rather obvious that modern applications should be structured in a way that permits an easy deployment to existing cloud infrastructure, such as Amazon Web Services (AWS). In this article I will cover the Amazon solution, which is quite popular nowadays; there is, of course, also Google Computing Platform, which goes hand in hand with Amazon and offers more or less comparable core services, but let us focus on AWS for starters.
As the web evolves, more and more businesses are shifting their applications and data from internally hosted to the cloud. They provide publicly available APIs to expose valuable data (resources) and business functionality. To provide controlled access to exposed resources, API should be secured somehow, and that is where OAuth comes into play.