Infrastructure as a Service, like OpenStack and AWS, have made it possible to consume infrastructure on demand. It’s important to understand the ways in which both humans and machines interact with IaaS offerings in order to design optimal systems that leverage all possible automation opportunities. I drew the diagram below to help illustrate. Everything is an API At the heart of IaaS are REST APIs that provide granular access to every resource type, such as compute, storage and network. These APIs provide clarity about which resources are being managed and accommodate the type......
Continue Reading
There are some high quality resources that already cover the OpenStack API, so this is a YEA (yet another example) post. See the resources section below for some helpful links. OpenStack APIs provide access to all OpenStack components, such as nova (compute), glance (VM images), swift (object storage), cinder (block storage), keystone (authentication) and neutron (networking). Authentication tokens are valid for a fixed duration, after which they expire and must be replaced. Each service requires it’s own token. Services that are hosted on the same logical server are typically accessible over different ports.......
Continue Reading
I have recently had to work with a few REST APIs that exhibited some poor design choices that I had previously assumed would be obvious. Since they may not be obvious to everyone, I wanted to highlight them. Idempotent operations When an operation is idempotent that means that an end state will be identical regardless of how many times the operation is executed. If the end state is dependent on the number of times an operation is executed, then it is not idempotent. Why is this important? REST interfaces should assume unreliable networks......
Continue Reading
Recently I was debugging a REST client class in Java. The service I was calling simply returned that the request was incomplete. Without access to the service logs and without more meaningful feedback from the service, I decided to create an echo script that would allow me to see exactly what my REST client was sending. For simplicity I used a LAMP installation on Ubuntu running inside virtual box on my Windows 7 development machine. I could have installed something like WAMPServer, but I prefer to leave my machine as clean as possible.......
Continue Reading
In a previous article I demonstrated one way to create a RESTful interface using a plain Java Servlet. In this article I wanted to extend that to include JSON serialization using Jackson. I found a very simple article showing a basic case mapping a POJO to JSON and back again. However, when I copied this straight over I got the following error: org.codehaus.jackson.map.JsonMappingException: No serializer found for class DataClass and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationConfig.Feature.FAIL_ON_EMPTY_BEANS)org.codehaus.jackson.map.JsonMappingException: No serializer found for class DataClass and no properties discovered to create......
Continue Reading
For a recent project I found that a RESTful interface would be appropriate. My first inclination was to use Jersey (or one of the JAX-RS implementations available). The environment where this new REST API would deploy is still using Java 1.5. This became a major roadblock when I was found that none of the JAX-RS implementations provide support for the Java 1.5 virtual machine. This is not surprising since it’s few YEARS past EOSL (end of support life) for Java 1.5, but disappointing still the same. After spending a day or so with......
Continue Reading
I did some investigation into building the RESTful API for the software licensing system using wicket. At first I was encouraged that URL management was so easy (nevermind that really old article I just linked to). Wicket Not Ideal for RESTful APIs In the end I decided that wicket was not a good choice for the RESTful API. The crux came in treating HTTP methods differently. In other words, for a given resource URI, I want to do something different for GET, POST, PUT and DELETE. That’s not one of wicket’s strengths, so......
Continue Reading
I’m starting to build out the RESTful API for the software licensing system. The first api call to implement is this http://mysite/api/sitelicenses/?apikey=KEYVAL That came from the initial design documents and implicitly suggests that there is a difference between the resource and parameters passed in when asking for the resource. This distinction is important and came up today when I was thinking about pagination. As the API is defined currently, the above URI would return all site licenses associated with an apikey. The first thought that came to mind was that the number of......
Continue Reading
In the first article in this series, I sketched out some of the basic design ideas for the wordpress plugin licensing system. The next step is to come up with some more concrete details about how the application will work, what information it will manage and what the interfaces will look like when accessing it. I really like using the UML as I flesh out a design. In particular I find the class diagram and activity diagram useful. I frequently make use of stereotypes to extend the meaning of my classes. I’m not......
Continue Reading