What is Sinatra?
Sinatra is a DSL, or "domain-specific language," specifically utilized in Ruby for creating web applications. It runs on Rack, and is a light framework intended to make database queries simple with some intuitive, built-in methods. Using Sinatra methods, we can create the logic that is implemented when requests are made to a Sinatra server. This includes defining get, post, patch, and delete fetch requests, along with some other options such as options, link, and unlink.
What does Sinatra routing look like?
Sinatra routes are written with a ruby block beginning with the request method, the specified route, and then the code block to be executed. A very simple get request would be written like this:
When visiting this route in our web browser, we see this:
What's happening here is pretty straight-forward: by visiting the route 'localhost:9292/getexample', we are making a get request to our Sinatra server, and we have already told our server what to do! When a get request is made to this route, the block statement returns a string, 'This is a simple get request'. Then, our browser displays the content. Pretty easy.
Routing using other fetch requests is just as simple. We start the code with the expected fetch method type, then define the route, then write the code for the server to execute, determining what response we'd like to be sent back to the client (the maker of the request). Here's what some other route blocks might look like:
Parameters using params hash
You may have noticed in the previous example the ':id' part of the request route. This is an intro into how we can spice up our routing a bit and make our requests a little more dynamic. Remember, when we write our routes, we want to try our best to maintain RESTful practices. In this case, '/:id' should be utilized when viewing a specific instance of a class or group.
These are called named parameters, and the variable name gets saved in a special object called the params hash. Using our previous routing examples, here is how to call the params has, and what it looks like when sent back to the client (note: the .to_json method automatically converts data to a json format, helping package information in a readable format before sending it back to the web browser):
In our sinatra server, we are declaring a route of "/examples/:id", and whatever follows the "/examples/" part of the route is saved in the params hash, within our named parameter :id. By sending the params hash back to the client, we can see that our id number has been saved in the params hash, and would be accessible via params[:id]. Sinatra is capable of accepting multiple parameters from the route using different named parameters:
By declaring an :id, :name, and :date parameter, we can save all of those values from the route into our params hash. Since params is just a ruby hash, we can access whatever value we want by calling the parameter name using bracket notation, e.g. params[:name], which would give us "Robert". We also have access to a wildcard option in our routing called a splat parameter. By using a * in the route name, we can be a little more vague in naming our parameters:
The * saves all matching patterns to the :splat parameter, which has an array of all of the wildcard values.
It is worth noting that sinatra will execute the first route that matches the received route, and that an ending '/' can make a route unique, e.g. '/example/' !== '/example'.
Query Parameters
Another way to utilize the params hash is through query parameters, which is similar to the previously mentioned routing parameters, but are used within a single route. This can be useful when accepting search criteria or filter options. A request to get a list of food items, but only vegetarian options, is still recognized by the server like this:
This route, however, matches '/food' as well as '/food?AnythingHere'. To add a vegetarian filter to our search, the client sends a get request to '/food?diet=vegetarian', and our server does the work of adding that information to the params hash.
We can combine our query parameters with our named parameters to store a lot of information in our params hash, and it only requires a single route on the server side:
The params hash is very versatile and can be utilized to store and access a lot of information, helping make our server very dynamic.
Wrap Up
Routing can get a lot more complicated, and Sinatra gives us access to a lot of other methods and ways to receive requests. We can define conditions for our routes, use regular expressions, and even have optional parameters. The params hash is also what sinatra uses when receiving a post request. All of the key/object pairs in a post request are saved into the params hash so that they can be utilized in the block statement for the post request. That's a lot of use for one hash!
Top comments (0)