The RESTful API has a funny place in the software development world: it’s widely regarded as the best general-purpose pattern for building web application APIs, and yet it’s also nebulous enough of a concept to cause endless disagreements within teams over exactly how to implement one.
Do I make my endpoint
/companies/123/? How about
/locations/?company=123 ? How do I handle versioning the API? Why shouldn’t I send a POST request to trigger an action on the server? If a backend task can take many seconds to process, how do I represent that in the API?
“It’s going to be the coolest thing ever.”
You know enough by now to be doubtful when a client makes this statement, but you’re willing to entertain the idea that this may not, in fact, be a tragedy in the making.
“It’s going to be a music machine – like, full keyboard and everything – but each of the keys is going to be mapped to – wait for it – cat sounds! We’ll call it the ‘Meowsic Machine’! Oh, and we need it to be accessible to everyone via the Web. Which is easy, right?
You are reminded that the universe can be a cruel place.
It’s now your job to make this happen. Over the course of a few posts, we’re going to look at the Web Audio API, and build the Meowsic Machine together. In the process, we’ll also enjoy a dalliance with Vue.js, and dip our toes into the deep-end with Web Workers. Today, we take the first step in this historic journey—convincing the browser to actually let us play sounds.
Ian Bicking’s WebTest is a helpful module for running functional tests against a WSGI app. You may already be using it, it’s the suggested way to test Pyramid apps, TurboGears and Google App Engine, and (although I have no experience with this) you can use it with Django (apparently this is a good idea) and Flask. It’s not very complicated but in my haste to get things done I overlooked a couple of its nicest features.
With apologies to Mr. Poe:
I was fuming in frustration, sitting clicking at my station,
I’ll spare you some narration, but I was getting pretty sore.
‘Surely there must be some method, whereby changes are detected,
And perhaps then be injected into my page’s DOM!’, I swore.
‘Some way to edit CSS without it being such a chore,
And click Refresh nevermore.’
So I then took up the challenge, and began a quest for knowledge
on this strange mysterious thing for which I’d searched some times before.
But amidst auto-refresh plugins, and bookmarklets by the dozen,
Nothing did I find which would my page’s state restore.
Then I chanced upon a newsfeed and this here did it implore:
“BrowserSync, you will adore.”
— not quite Edgar Allen Poe
Deploying your webapp is an important part of the web development equation – your client’s site isn’t going to attract a lot of attention sitting in your local dev directory. Deployment concerns tend to fall to the bottom of the priority list, though, and the end result tends to be kludgy, hastily thrown-together deployment scripts; and because they are so kludgy and, often, time consuming, when time crunches threaten, a developer may resort to making changes directly on the remote server that need to be (but sometimes never are) backported to the code living in your version control.
Wouldn’t it be better if you could deploy your newest code with a single command, using the same tool you use for version control? One
git push, and your site is serving your newest commits. No more kludgy, multi-part scripts, no more threat of overwriting critical fixes with the next deploy.
Let’s make that happen.