In addition to invoking Lambda functions and other AWS services such as S3, the API Gateway can also act as a proxy between the user and your http based service. For example if you already have a service based architecture you could integrate it with the gateway to maintain, monitor and secure a public API for your services. However, Amazon’s priorities seem to be on the former two integration methods, because when it comes to the details the HTTP proxy integration is quite painful at the moment. In this post I will highlight some of the pitfalls and provide workarounds.
Transparency makes the difference between a system that improves over time in production and one that stagnates on decays.
Spring Boot comes with a number of production ready endpoints that expose information about your application’s configuration and health. This insight is vital for monitoring. By default Spring Actuator functionality is accessible via Spring MVC. This is not ideal when you use Jersey (JAX-RS) as your primary web service framework. In fact, if you use Spring Boot’s Jersey Starter sample project, the endpoints don’t even work out of the box (see Issue #2025). In this post, I’m going to demonstrate how to expose the Actuator endpoints via Jersey.
One of Spring Boot’s many sample projects demonstrates how to configure Spring with Jersey. We’re using the JAX-RS API a lot in projects for developing of RESTful web services. It was designed for this specific task from the beginning, rather than retrofitted like Spring MVC was. Jersey also offers a reactive client API which supports a reactive programming model.
In this post I’m going to show how to use the the reactive Jersey client based on RxJava together with Spring Boot. This post will also address how to handle and communicate server side errors back to the client. Specifically there are some issues I’ve discovered which are related to using the reactive Jersey client together with the embedded Tomcat container.
Last week at our Hackathon I got my hands dirty with Swift. In particular I was using NSURLConnection to post JSON http requests to a 3rd party web service. The web service wasn’t documented. All I had were a few request examples that I knew were successful before. So I needed my web service client to produce similar http headers and a similar JSON body.
My first attempts caused the server to return a 500 Internal Server Error. Without any more details to go with, I suspected that maybe some header value or JSON value in my http request was formatted incorrectly. In order to confirm my theory, I needed a way to analyze the http request that my application was producing.
Unfortunately I wasn’t able to find a way to make NSURLConnection log out the complete request details including headers and payload. My next attempt was to use Charles, which is a Proxy that can be used to debug HTTP traffic. I was able to see all header values, but for some reason the JSON payload (raw body) was empty. After double and triple checking that I was correctly setting the HTTPBody of NSMutableURLRequest in my code and after changing numerous Charles settings, I still wasn’t able to see the actual payload of my request. Not wanting to lose any more time on this (we only had 2 days in total for our Hackathon projects), I decided to write a simple web server that would just print out all http request details.