I think people who are totally new to HTTP would be better served by initial examples that just show what's going on as a typical web page loads--what the browser sends in order to get scripts and css, following a link, submitting a form. That way, it's immediately obvious what the client and server are trying to accomplish, and those are completely familiar things.
This avoid situations where the listener is thinking: "Wait, what sort of software exactly is the client in this exchange? Why are we doing this? When would I write code that does this? What is this JSON for?"
I was able to tell what was going on with the /books examples, so maybe I'm just wrong and it's plenty easy to follow already.
Separately: At the beginning, to motivate the talk, you brought up an analogy about hiring an electrician -- it's not a bad analogy, but the direct approach would work fine:
- of *course* you want to know how things work inside and why.
- the nice libraries that supposedly do all that for you don't *really* hide HTTP effectively, even when things *are* working; many don't even try.
- and when they break, knowing HTTP is invaluable in debugging them.
- plus, if you don't know what's going on underneath, you could spend a ton of effort re-inventing things that HTTP already does well, like caching.
Comments
Comments are closed.
Good overview of HTTP.
Sorry this is so long...
I think people who are totally new to HTTP would be better served by initial examples that just show what's going on as a typical web page loads--what the browser sends in order to get scripts and css, following a link, submitting a form. That way, it's immediately obvious what the client and server are trying to accomplish, and those are completely familiar things.
This avoid situations where the listener is thinking: "Wait, what sort of software exactly is the client in this exchange? Why are we doing this? When would I write code that does this? What is this JSON for?"
I was able to tell what was going on with the /books examples, so maybe I'm just wrong and it's plenty easy to follow already.
Separately: At the beginning, to motivate the talk, you brought up an analogy about hiring an electrician -- it's not a bad analogy, but the direct approach would work fine:
- of *course* you want to know how things work inside and why.
- the nice libraries that supposedly do all that for you don't *really* hide HTTP effectively, even when things *are* working; many don't even try.
- and when they break, knowing HTTP is invaluable in debugging them.
- plus, if you don't know what's going on underneath, you could spend a ton of effort re-inventing things that HTTP already does well, like caching.
On the whole, though, good talk, nice work!