At this point you should be feeling fairly comfortable writing Sinatra applications. So far, we’ve focused primarily on the classic approach, where a single application exists in a single process. That’s only scratching the surface of Sinatra’s potential, however. Let’s take a deeper look at how Sinatra actually works. Once you understand what is going on backstage, it becomes significantly easier to take full advantage of the available API (or even extend it). To gain this understanding, we’ll dig into the source code and take a guided tour of what’s actually going on.
Sinatra follows Semantic Versioning, which basically states that Sinatra will not break backwards compatibility unless the major version (the first number of the version) is increased. So, any application written for Sinatra 1.2.3 will still work with Sinatra 1.3.0. Semantic Versioning requires an official and complete API specification. For Sinatra, this happens to be the README, which you can find here: http://www.sinatrarb.com/intro. You can learn more about Semantic Versioning at http://semver.org/.
Let’s start with a quick experiment. We saw earlier in the book how
parameters are passed into routes and extracted in the context of the
route via the
params hash; for example,
in a simple login form we may find
We mentioned previously that the various route definitions in a
Sinatra app (
post '/login' ...