A Couple of Things I've Learned from Building an HTTP Server

Building a server from scratch has been an interesting journey. I don’t know if I would call it fun (given some of the frustrations from reading an input stream), but it has definitely been an interesting challenge. I learned a ton from this project so far. I still have some requirements to meet for the server, but I wanted to take a brief second to write about a couple of things that I’ve learned so far.

What is a server? (Hint: it’s not all about the sockets!)

When it was time for me to take on the server project, I was absolutely lost and confused. When I thought of a server, I simply defined it as something that processed requests. I didn’t know how it processed anything. I started the project by learning everything I could about servers, sockets, and network programming in general. I was stuck on this notion that I had to know everything about sockets. But when I finally took a step back, I realized I didn’t really need to understand too much about sockets to create a server. I just needed to know the high level business concerns of a server. A server takes a request from a client, and returns a response. That’s it. And when I started to break this down, as far as implementation, this meant I needed to have a request reader, a request parser, a parsed request router, a response builder, and a response writer. No where in any of that did I mention anything about sockets, which is simply a minor communication detail between the server and the client. In fact, the more I worked on implementing the server, the less I even thought about sockets. It’s been a while since I’ve thought about sockets…a long while.

Difference between unit, integration, and acceptance tests...

Unit tests were clear to me, but during this project I kept having issues understanding what I needed to test or the relationships between other testing. I also wasn’t sure about the benefits of acceptance tests. Almost every day I found myself asking, "should I test that or is that covered under the acceptance tests?” Unit tests are for making sure indiviudal methods (or components) function as they should. These are the smallest unit of software. Integration tests combine multple units (or modules) to ensure that they interact appropriately. Integration tests inform on assembly and configuration. Finally acceptance tests tell us if the software solves the problem it sets out to do as defined by the business needs.