[Editor’s note: This is a cross-post from a Tumblr entry; I started to write it as a quick note because someone was wrong on the Internet, but by the time it was done, it was long enough to be a blog post in its own right.] What kind of string is this? http://example.com/path?query=foo Well, it’s a URI (Uniform Resource Identifier) as well as a URL (Uniform Resource Locator). But wait, that means the whole string (check RFC 2396) is resource identifier, which means the whole thing identifies a resource (literally).
The humble list is one of our simplest and yet most powerful data structures–so much so that we will even routinely write them out by hand. We put them on sticky notes to help us remember things we need to do or things we need to buy from the grocery store. We even use them for entertainment. In this post I’ll explain how to represent and manipulate lists using hypermedia techniques.
There is an ongoing (and interesting) discussion on the API-craft mailing list revolving around designing new media types for enabling hypermedia APIs primarily for programmatic consumption. As some folks may know, I like to use HTML as the media type for my hypermedia APIs. Steven Willmott opined I think the problem isn't "why not HTML" it's "why HTML" - if you strip out all the parts of HTML which are to do with rendering things for presentation you're left with almost nothing at all: <a> <h1>, <h2>, <h3> .
In a previous post, I described the underlying theory behind optimizing the throughput of a software development organization, which consists of a three-pronged attack: remove queuing delay by limiting the number of features in-flight remove failure demand by building in quality up front and fixing root causes of problems reduce average cycle time by experimenting with process improvements In this article, I’d like to provide an alternative visualization to help motivate these changes.
Ok, I’m going to tell you how to make your software development organization go faster. I’m going to tell you how to get more done without adding people while improving your time to market and increasing your quality. And I’m going to back it all up with queuing theory. [ By actually explaining the relevant concepts of queuing theory, not just by ending sentences with “…which is obvious from queuing theory”, which is usually a good bluff in a technical argument being had over beers.
Inspired by a talk about Clojure given by Rich Hickey at Philly Emerging Tech earlier this year, I’ve been toying with building a Java library of pure (immutable) data structures, starting with the Map implementation based on Phil Bagwell’s Hash Tries. Yes, I know I could probably just figure out how to use them straight out of Clojure by interoperating, but that would deprive me of an interesting coding exercise.
We’re going through a process mapping exercise at work just to try to understand how we get things done. Now, we are running what I would describe as “scrumfall”; doing Scrum for development but having that sit inside a traditional waterfall process. The waterfall is run iteratively and pipelined, although the degree of true pipeline isn’t what most people think it is, due to developers having to support upstream and downstream activities like backlog grooming and addressing bugs in QA.
At work we were having a discussion about how we wanted to do SSL termination for a particular web service. We had narrowed the possibilities down to doing hardware SSL termination in our load balancer or doing software SSL termination in an Apache layer sitting in front of our web apps. During the course of the conversation, we talked about factors like performance (would there be a noticeable effect on latency), capacity (were we already CPU bound on the servers that would run the Apaches), maintainability (is it easier to update configs on a single load balancer or to script config changes across a cluster with 40+ servers), cost (how much does the SSL card cost), and scalability (will we be able to expand the solution out to higher traffic levels easily).
I’ve been spending a lot of time thinking about RESTful web services, hypermedia APIs, and I’ve started to discover several design patterns as I’ve begun to play around with these in code. Today, I want to talk about the granularity of resources, which is roughly “how much stuff shows up at a single resource”. Generally speaking, RESTful architectures work better with coarser-grained resources, i.e., transferring more stuff in one response, and I’ll walk through an example of that in this article.
The REST architectural style is defined in Roy Fielding’s thesis, primarily chapter 5, where the style is described as a set of architectural constraints. A quick summary of these constraints is: client-server The system is divided into client and server portions. stateless Each request from client to server must contain all of the information necessary to understand the request. cache Response data is implicitly or explicitly marked as cacheable or non-cacheable.