This is one of my all time favorite dialogs between a developer and his wife over a subject (HTTP and REST) that is the backbone of the web. The truth of the matter is that many professional developers have had the same questions the wife has asked. I think this dialog completely clears up the many confusions that everyone has with the concept of REST.

Wife: Who is Roy Fielding?

Ryan: Some guy. He’s smart.

Wife: Oh? What did he do?

Ryan: He helped write the first web servers and then did a ton of research explaining why the web works the way it does. His name is on the specification for the protocol that is used to get pages from servers to your browser.

Wife: How does it work?

Ryan: The web?

Wife: Yeah.

Ryan: Hmm. Well, it’s all pretty amazing really. And the funny thing is that it’s all very undervalued. The protocol I was talking about, HTTP, it’s capable of all sorts of neat stuff that people ignore for some reason.

Wife: You mean http like the beginning of what I type into the browser?

Ryan: Yeah. That first part tells the browser what protocol to use. That stuff you type in there is one of the most important breakthroughs in the history of computing.

Wife: Why?

Ryan: Because it is capable of describing the location of something anywhere in the world from anywhere in the world. It’s the foundation of the web. You can think of it like GPS coordinates for knowledge and information.

Wife: For web pages?

Ryan: For anything really. That guy, Roy Fielding, he talks a lot about what those things point to in that research I was talking about. The web is built on an architectural style called REST. REST provides a definition of a resource, which is what those things point to.

Wife: A web page is a resource?

Ryan: Kind of. A web page is a representation of a resource. Resources are just concepts. URLs—those things that you type into the browser…

Wife: I know what a URL is..

Ryan: Oh, right. Those tell the browser that there’s a concept somewhere. A browser can then go ask for a specific representation of the concept. Specifically, the browser asks for the web page representation of the concept.

Wife: What other kinds of representations are there?

Ryan: Actually, representations is one of these things that doesn’t get used a lot. In most cases, a resource has only a single representation. But we’re hoping that representations will be used more in the future because there’s a bunch of new formats popping up all over the place.

Wife: Like what?

Ryan: Hmm. Well, there’s this concept that people are calling Web Services. It means a lot of different things to a lot of different people but the basic concept is that machines could use the web just like people do.

Wife: Is this another robot thing?

Ryan: No, not really. I don’t mean that machines will be sitting down at the desk and browsing the web. But computers can use those same protocols to send messages back and forth to each other. We’ve been doing that for a long time but none of the techniques we use today work well when you need to be able to talk to all of the machines in the entire world.

Wife: Why not?

Ryan: Because they weren’t designed to be used like that. When Fielding and his buddies started building the web, being able to talk to any machine anywhere in the world was a primary concern. Most of the techniques we use at work to get computers to talk to each other didn’t have those requirements. You just needed to talk to a small group of machines.

Wife: And now you need to talk to all the machines?

Ryan: Yes – and more. We need to be able to talk to all machines about all the stuff that’s on all the other machines. So we need some way of having one machine tell another machine about a resource that might be on yet another machine.

Wife: What?

Ryan: Let’s say you’re talking to your sister and she wants to borrow the sweeper or something. But you don’t have it – your Mom has it. So you tell your sister to get it from your Mom instead. This happens all the time in real life and it happens all the time when machines start talking too.

Wife: So how do the machines tell each other where things are?

Ryan: The URL, of course. If everything that machines need to talk about has a corresponding URL, you’ve created the machine equivalent of a noun. That you and I and the rest of the world have agreed on talking about nouns in a certain way is pretty important, eh?

Wife: Yeah.

Ryan: Machines don’t have a universal noun – that’s why they suck. Every programming language, database, or other kind of system has a different way of talking about nouns. That’s why the URL is so important. It let’s all of these systems tell each other about each other’s nouns.

Wife: But when I’m looking at a web page, I don’t think of it like that.

Ryan: Nobody does. Except Fielding and handful of other people. That’s why machines still suck.

Wife: What about verbs and pronouns and adjectives?

Ryan: Funny you asked because that’s another big aspect of REST. Well, verbs are anyway.

Wife: I was just joking.

Ryan: It was a funny joke but it’s actually not a joke at all. Verbs are important. There’s a powerful concept in programming and CS theory called polymorphism. That’s a geeky way of saying that different nouns can have the same verb applied to them.

Wife: I don’t get it.

Ryan: Well.. Look at the coffee table. What are the nouns? Cup, tray, newspaper, remote. Now, what are some things you can do to all of these things?

Wife: I don’t get it…

Ryan: You can get them, right? You can pick them up. You can knock them over. You can burn them. You can apply those same exact verbs to any of the objects sitting there.

Wife: Okay… so?

Ryan: Well, that’s important. What if instead of me being able to say to you, “get the cup,” and “get the newspaper,” and “get the remote”; what if instead we needed to come up with different verbs for each of the nouns? I couldn’t use the word “get” universally, but instead had to think up a new word for each verb/noun combination.

Wife: Wow! That’s weird.

Ryan: Yes, it is. Our brains are somehow smart enough to know that the same verbs can be applied to many different nouns. Some verbs are more specific than others and apply only to a small set of nouns. For instance, I can’t drive a cup and I can’t drink a car. But some verbs are almost universal like GET, PUT, and DELETE.

Wife: You can’t DELETE a cup.

Ryan: Well, okay, but you can throw it away. That was another joke, right?

Wife: Yeah.

Ryan: So anyway, HTTP—this protocol Fielding and his friends created—is all about applying verbs to nouns. For instance, when you go to a web page, the browser does an HTTP GET on the URL you type in and back comes a web page.

Web pages usually have images, right? Those are separate resources. The web page just specifies the URLs to the images and the browser goes and does more HTTP GETs on them until all the resources are obtained and the web page is displayed. But the important thing here is that very different kinds of nouns can be treated the same. Whether the noun is an image, text, video, an mp3, a slideshow, whatever. I can GET all of those things the same way given a URL.

Wife: Sounds like GET is a pretty important verb.

Ryan: It is. Especially when you’re using a web browser because browsers pretty much just GET stuff. They don’t do a lot of other types of interaction with resources. This is a problem because it has led many people to assume that HTTP is just forGETing. But HTTP is actually a general purpose protocol for applying verbs to nouns.

Wife: Cool. But I still don’t see how this changes anything. What kinds of nouns and verbs do you want?

Ryan: Well the nouns are there but not in the right format.

Think about when you’re browsing around amazon.com looking for things to buy me for Christmas. Imagine each of the products as being nouns. Now, if they were available in a representation that a machine could understand, you could do a lot of neat things.

Wife: Why can’t a machine understand a normal web page?

Ryan: Because web pages are designed to be understood by people. A machine doesn’t care about layout and styling. Machines basically just need the data. Ideally, every URL would have a human readable and a machine readable representation. When a machine GETs the resource, it will ask for the machine readable one. When a browser GETs a resource for a human, it will ask for the human readable one.

Wife: So people would have to make machine formats for all their pages?

Ryan: If it were valuable.

Look, we’ve been talking about this with a lot of abstraction. How about we take a real example. You’re a teacher – at school I bet you have a big computer system, or three or four computer systems more likely, that let you manage students: what classes they’re in, what grades they’re getting, emergency contacts, information about the books you teach out of, etc. If the systems are web-based, then there’s probably a URL for each of the nouns involved here: student, teacher, class, book, room, etc. Right now, getting the URL through the browser gives you a web page. If there were a machine readable representation for each URL, then it would be trivial to latch new tools onto the system because all of that information would be consumable in a standard way. It would also make it quite a bit easier for each of the systems to talk to each other. Or, you could build a state or country-wide system that was able to talk to each of the individual school systems to collect testing scores. The possibilities are endless.

Each of the systems would get information from each other using a simple HTTP GET. If one system needs to add something to another system, it would use an HTTP POST. If a system wants to update something in another system, it uses an HTTP PUT. The only thing left to figure out is what the data should look like.

Wife: So this is what you and all the computer people are working on now? Deciding what the data should look like?

Ryan: Sadly, no. Instead, the large majority are busy writing layers of complex specifications for doing this stuff in a different way that isn’t nearly as useful or eloquent. Nouns aren’t universal and verbs aren’t polymorphic. We’re throwing out decades of real field usage and proven technique and starting over with something that looks a lot like other systems that have failed in the past. We’re using HTTP but only because it helps us talk to our network and security people less. We’re trading simplicity for flashy tools and wizards.

Wife: Why?

Ryan: I have no idea.

Wife: Why don’t you say something?

Ryan: Maybe I will.

Thanks to Ryan Tomakyo for originally posting this on his blog. The original article can be found here.

If you enjoyed this post please share with someone that you think would also enjoy and if you would like to see more posts like this then head over to my technical blog at jasonroell.com.

Software applications are getting more and more complex and each platform for developing applications these days seems like its operating on a higher and higher level of abstraction to hide that complexity from the developer.

In particular, when I say “a higher level of abstraction”, I am talking about “managed languages”. “Managed code” is a term coined by Microsoft to identify computer program source code that requires and will execute only under the management of a Common Language Runtime (virtual machine), typically the .NET Framework, or Mono. However, this also applies to frameworks such as Java and the JVM (Java Virtual Machine). The individual VMs differ from each other, but the core concept of “managed code” remains the same.

I am a big fan of languages/platforms that allow you to operate at a high level, handle your memory management, transform and optimize your code for the hardware it is running on, and much more.

However, I am always questioned from other developers with “Aren’t managed languages slow? Shouldn’t we use C++ for everything?”

It seems to me that this layer of management between your program and the computer’s processor can be a major source of anxiety for developers who assume that it must add some significant overhead.

There are many unfortunate stereotypes in this world. One of them, sadly, is that managed code cannot be fast. This is just not true. What is closer to the truth is that the CLR (Common Language Runtime) or the JVM (Java Virtual Machine) makes it very easy to write slow code if you are sloppy and not careful.

When you build your C#, VB.NET, or other managed language code, the compiler translates the high-level language to Intermediate Language (IL) and metadata about your types. When you run the code, it is just-in-time compiled (“JITted”). That is, the first time a method is executed, the CLR will invoke the compiler on your IL to convert it to assembly code (e.g., x86, x64, ARM). Most code optimization happens at this stage. There is a definite performance hit on this first run, but after that you will always get the compiled version (there are ways around this first-time hit when it is necessary).

In my experience with .NET/Java the overhead is worth it, and the supposed performance degradation is almost always exaggerated. Often, the performance problems developers blame on .NET/Java and other managed languages are actually due to poor coding patterns and a lack of knowledge of how to optimize their programs on this framework.

Skills gained from years of optimizing software written in C++, C, or VB may not always apply to managed code, and some advice is actually detrimental. Sometimes the rapid development nature of .NET/Java can encourage people to build bloated, slow, poorly optimized code faster than ever before. Certainly, there are other reasons why code can be of poor quality: lack of skill generally, time pressure, poor design, lack of developer resources, laziness, and so on.

The bottom line is that the amount of performance optimization you get out of your application is directly proportional to the amount of understanding you have not only of your own code, but also your understanding of the framework, the operating system, and the hardware you run on. This is true of any platform you build upon.

As most things in life, managed code has its pros and cons and obviously is not a silver bullet. Pros being that the developer can focus on what is important to the business and business logic rather than the details of worrying about pointer addresses and thread management. Some of my favorite advantages managed code provides over it’s unmanaged brethren are as follows:

1. Advanced Language features – Delegates, anonymous methods, and dynamic typing.
2. Automatic memory management – I think this speaks for itself…
3. Easier extensibility – With reflection capabilities, it is much easier to dynamically consume late-bound modules.
4. Safety – The compiler and runtime can enforce type safety (objects can only be used as what they really are), boundary checking, numeric overflow detection, security guarantees, and more. There is no more heap corruption from access violations or invalid points.

Of course its not all rainbows, butterflies , and unicorns (that would be nice). The cons for manage code are that operating at this level requires understanding the platform that you are running on and how it handles some of the lower level details for you and recognizing how to use the platform to suite your individual needs. Understanding how to optimize your code for the best performance can sometimes be more complicated with managed code if you are not familiar with performance optimization on these platforms.

Performance optimization can mean many things, depending on which part of the software you are talking about. In the context of managed applications, think of performance in four layers (in order of greatest potential impact):

1. Algorithms – Here is where your computer science fundamentals come into play. Remember asymptotic time complexity and analysis of functions as their input approaches infinity? This is where the most time is either gained or lost in programming. (If you aren’t familiar with asymptotic time complexity and “Big-O”, there’s a post for that)
2. Framework – This is the set of classes provided by the platform owner (Microsoft .Net Framework libraries, or the Java Standard Edition libraries) that provide standard functionality for things like strings, collections, parallelism, or even full-blown sub-frameworks like Windows Communication Foundation. You need to understand how to use your preferred framework and be familiar with most of its APIs.
3. CLR/JVM – Below the Framework is the virtual machine that is running your managed code. Understanding how this is implementing and how it works will provide the next level of potential performance gains.
4. Assembly Code – This is where the code hits the metal, so to speak. Once the CLR/JVM JITs the IL/byte code you are actually running processor assembly code. If you break into a managed process with a native debugger, you will find assembly code executing. That is all managed code is – regular machine assembly instructions executing in the context of a particularly robust framework.

Remember that when doing performance analysis, you should always start at the top layer and move down.

Make sure your program’s structure and algorithms make sense before digging into the details of the underlying code. Macro-optimizations are almost always more beneficial than micro-optimizations.

If you liked this post, please share it, like it, or subscribe to my blog atjasonroell.com. Doing so helps me decide what is the best content to post and deliver to all you reading! Thanks again, and have a great day!

I am currently (at the time this article was written anyway) working for a large (6,000+ people) Fortune 500 company. However, this was not always the case.

Actually, I started my career (straight out of college) for a small biotech startup (Assurex — very cool and very advanced personalized medicine company BTW that you may want to check out). At the time of graduation, I had two offers on my table (this was a shock to me already!) for a full time software engineering position. One was for this cool tech startup, and the other was for a large Fortune 500 insurance company in the heart of downtown Cincinnati.

This was a really tough decision for me. I certainly thought that the small biotech startup sounded a lot cooler (DNA extraction and gene analysis!? Common that is cool). However, I was also tempted to pick the safe, large, and financially stable enterprise company that I knew would be around for a long time and could be a good place to start my career. Assurex (the small startup) was really neat but when I say small startup, I mean SMALL startup. There was only eight other employees in the company and their meeting room was literally a garage (no joke!).

Well, against what my mother wanted me to do (take the safe option), I decided to take a chance with the cool startup. Yeah, I wasn’t making as much money at the startup as I would have been at the large enterprise, but I was doing something that I genuinely believed could change the world (and it has, just check out this TEDx talk about the technology). Also, I believed that I had a lot to learn, and after meeting people at Assurex, I knew they would provide me with the greatest learning environment over the large company. I literally sat right in between Assurex’s Vice President of Software Development and the head of Quality Assurance and IT. Needless to say, I was learning more stuff in a few months after working there than I had in 4 years in college and was learning from the experts themselves.

The story doesn’t end there though. How could I compare the two companies if I have only worked at a small startup? Well stay with me, I am getting to that.

Assurex began to really start growing fast around 2010 and 2011 as the rest of the world caught on to what we were doing. I saw the company out grow the garage and move into a facility probably ten times as big as our old space (complete with a gym and a swimming pool).  I began to see new faces everyday and quickly felt like I no longer knew everyone in the company. Soon we were over 250+ employees toward the end of 2014. It was exciting to see so much growth and to learn so much in the process.

That is when I decided that it was time to for me to move on.

Weird timing? Some people say so. I enjoyed so much of the camaraderie that you have with a smaller startup and the feeling that I was truly making a difference with every line of code that I wrote (I know that my code still made a big impact, but it just didn’t feel the same to me).

Anyway, I am a firm believer in pushing yourself out of your comfort zone and trying new things that you have yet to master. I wasn’t learning at the same rate that I was when I first joined Assurex and I was ready for a new challenge that would push me to the next level.

Enter, “The Large Enterprise”.

At this time, I believed that the large enterprise (6000+ or more employees) would be the best place for me to learn about situations that smaller companies don’t have to deal with yet (serving millions of customers, and dealing with very large teams and projects that require strong communication skills across domains).

I ended up taking a job at a large insurance company in the heart of downtown Cincinnati.

Wait… That sounds familiar doesn’t it?

Yep, that is because I was lucky enough to be contacted and offered a Sr. Software Engineering job from the same company that offered me a job back in 2010 when I chose Assurex. Weird how that stuff works out isn’t it?

Well, I have been with the “large enterprise company” (Great American Insurance) for over a year now and can say that I have learned a lot from them as well, mainly in the areas that I specified above. I like it here as well but I don’t think any place will ever have the magical feel of a startup that is beginning to take off. That wasn’t the reason I joined Great American though. I have grown here and met some very intelligent people in the process that I plan to stay connected with the rest of my life. I’ve worked on systems that were larger than anything a startup could imagine and improved my performance skills when dealing with a large user base and heavy traffic.

If you are in the dilemma that I was in and having a hard time deciding which type of company you should choose, I offer this suggestion and advice:

You should pick the team you are most excited to work with, will learn the most from, and most want to be like.

Big companies and startups both have advantages and disadvantages. Also big companies vary a lot, and startups even more so. I can’t give blanket statements that will be true for every startup or big company and they may be different from the companies that you are considering.

Some questions you should ask yourself are:

1. Do You Know What Your Dream Career Would Be, or Are You Still Deciding?
2. What Resources Do You Need to Reach Your Goals?
3. What Kind of Influence Do You Want—and How Quickly?
4. What Environment Will Really Help You Succeed?
5. Who Will I be Working With. How Closely?

For me personally, it comes down number 5 from the list above more than all of the others. I would choose based on the specific people you’ll be working with. They’re the ones who’ll teach you the most, who’ll bring you along to their future jobs, who you’ll eventually start startups with. I’d take almost any job, if it was with the best possible people.

If you liked this post, please share it, like it, or subscribe to my blog at jasonroell.com. Doing so helps me decide what is the best content to post and deliver to all you reading! Thanks again, and have a great day!