APIs to Zip Drives

How many HTTP Status Codes can you name? We all know a few of the major ones to be sure: 200 - OK, 301 - Moved, 404 - Not Found, 500 - Unavailable... Would you believe me if I told you there were more than 60? You don't have to, check it out for yourself: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes Often when building REST APIs, I have found people defaulting to some of the better known HTTP Status codes - to a fault. Sometimes this is because they are simply updating existing services where the misuse is already coded to duplicate the functionality as part of new REST APIs initiatives, and sometimes it is because they are using codes that work even though there are more specific and better status codes of which they are unaware. An example may be using a 403 Forbidden in place of a 429 for rate limit exceptions. Some services have major aberrations, such as using HTTP Status 200 (Success) to relay everything, even failure messages. While REST APIs may be functional u

It seems like every day now we see news about new cyber attacks, security breaches of high profile companies, and steadily rising growth of awareness of security concerns. It only makes sense then that customers of IT solution vendors should demand more in terms of security assurances around the software and products they use. We see these requirements come up on RFI/RFP type documents, but often they are not fully vetted or audited until post-deployment. We have seen more requirements creeping up as well around standards such as FedRAMP, ISO 27001, etc., but often these are focused solely on cloud-based and shared service type deployments, and are only post-deployment type certifications, which can be adhered to with bolted-on security after issue discovery. There is an inherit flaw in this type of post-deployment adherence type logic. Products should not just be customize-able to hit security targets and should not only be focused on being vulnerability-free. Products should be desi

Slides from my most recent webinar. Come view the recording to explore further! https://www.axway.com/en/webinar/security-risks-web-services-and-api-interfaces-are-you-ready

What is an API Product? This is a concept I have been trying to define in full for a bit now, and haven't found any great write ups on. With that in mind, as always this is a learning and discovery blog, and that's the aim here. I encourage discussion on the topic, and for you to consider this a working definition, share your thoughts and opinions, and hopefully find what I have collected here somewhat useful. To those of you that have read my blogs, attended my webinars, or seen any of my presentations, you know I like to relate things to analogies. So to answer this question, let's start with a scenario... Say you are man shopping for a few dress shirts for work (feel free to swap pronouns and clothing articles as desired). You hop onto the home page of your favorite generic shopping site and start to look for what you need. What is the first thing you click on to start to narrow your search? Often you will see several departments (eg. beauty, kids, jewelry, watches)

The Prime Directive - Open more technology doors without increasing risk. I can distinctly recall being fresh in the Federally focused aspect of my career and having a conversation with a customer where he said to me "We don't measure failure in dollars, but in the loss of lives." It was a powerful statement that has stuck with me ever since that speaks to the sensitivity of the data and the critical nature of US Federal systems. The challenge becomes that this creates a situation where disruption can be far from ideal, and risk-adverse strategies with a strong focus on security are often paramount.  And yet, recent times have brought an explosion of new technologies and capabilities with tactical and practical value that cannot be ignored. Servicemen and women look to utilize their own devices to accessing PII focused data and services, or basic applications such as time sheets, without all the hassle of going through CAC-secured desktop systems. Officers in command wa

"Mobile is not a device, it is a digital strategy and supporting enterprise architecture." This has been a favorite statement of mine for a while now when discussing mobile initiatives. As mobile application consumers, generally what you see is the end user application only, and not the underlying components that enable the delivery of the functionality and data to your mobile device. Similar capabilities to desktop app or desktop web experience often seem to lead to the misconception that what you see is the same solution, simply ported to a mobile device, when the truth is that a successful mobile experience encompasses far more. Too often we see tough lessons learned as traditional desktop development teams without mobile development experience are tasked to 'make a mobile app and support omnichannel' and IT teams are told to support these requirements with no new investment in architecture to support mobile channels. Unfortunately, when digitizing services and c