Project Ramon

A learning journey from a Ruby noob perspective

Net::HTTP and URI Library tour


Hello, today I’ll be continuing my efforts while learning more about API interfacing.

This is day 3 of attempting to integrate a third-party api into my Rails project, and I must say that I haven’t made much progress. That being said, I will be covering the Net::HTTP and URI documentation to try and gain a better grasp on issuing requests and handling response data when interacting with an api.

Net::HTTP provides a library used to build HTTP user-agents, or software that acts on our behalf. In order to gain access to the methods that this library provides to communicate, all we have to do is add require 'net/http' to the top of the file we’re using to interface with the api.

URI is a module providing class methods to handle URIs. We don’t have to add require 'uri' to our file if we’ve already required 'net/http' as its automatically done for us.

Lets briefly go over what some of these methods do.


There are a couple of ways to read information from an api using this library. We can gain access directly to the URI through Net::HTTP.get('', '/index.html'), passing in the host and URI as separate arguments. There is also the option of passing a uri to get where uri is assigned the complete url string like so:

There are parameter options we can add to our URI as well. To add them, we can just store them in a hash like so:

URI Module

There are three features listed in the URI documentation:

Screen Shot 2014-02-18 at 4.45.55 PM

This module provides a few methods that will identify different parts of a URL.

You can actually just go into irb in your terminal and try these out. Remember to require 'net/http' once irb starts up as this will include both libraries we’re covering today.

Here’s a look at the output from my window:

Screen Shot 2014-02-18 at 4.58.02 PM

In addition to these methods, you can also join, split and extract strings. Here’s a quick example using .join.

In closing, I suggest that if you’re wanting to get into learning more about API’s take a look at Net::HTTP and URI.

And if you know of any up-to-date resources for better understanding how to interface with apis leave a comment! Here are a couple of resources that I’ve found useful or plan to read/purchase in the near future.

Net::HTTP Cheat-sheet by: Ruby Inside

A stack-overflow about external api placement in a Rails app

Designing Hypermedia APIs by: Steve Klabnik

More to come, stay tuned…


Categories: Ruby on rails

Tags: ,

6 replies

  1. I would also mention the open-uri module, which is a super-simple wrapper over net/http. I usually use it when all I need is issuing a GET request (then you can do that by simply calling open(url) – after requiring the module)

    Then, if I need POST or PUT, I turn to Net::HTTP

    And then, if I need to maintain state across the requests (cookies), or need to follow redirects automatically, I turn to HttpClient. So it’s a bit like going from bottom to the top depending on how much of HTTP protocol feature-set is needed.

    What kind of problem(s) with talking to an external API have you faced exactly ?

    • Hello Marek!

      I’m not confident in making requests. I need to pass api key and or secret with every request and not sure of how. My understanding so far of this process would be to issue a GET request in an index action for example. I would pass in the key and secret to my request along with the end point uri to ‘read’ the resources. And then handle the response data similarly using libraries you mentioned.

      Does that describe the process or am I overlooking some steps? What does a typical file structure look like for this? Do I create an api folder with a controller named after the api?

      I think I understand some basic pieces but not how to put them together into a complete request/response handler.

      • I think you have to pass that information with every request until you use some sort of authentication token? Are you wrapping the keys and secrets in environment variables or are you hardcoding them? Don’t hardcode them, that’s a big no-no.

      • Hello Justus, Thanks for the env variable heads up.

      • Hey,

        The way you should include the API key with the request should be documented in the API doc – sometimes it’s a special request param, sometimes it could be a special HTTP header – and sometimes could be both (I was recently working with BigCommerce API and they accepted both variants).

        I also think that you DON’T include your ‘secret’ – there is a reason why it’s called a ‘secret’ after all. Usually a ‘secret’ is something you keep on the server and never expose to the outer world. Instead, you would typically use it to SIGN the request, forming a digest/hash. This way, you are making a proof that it was really YOU – a person having a valid API key – who generated the request (because only the person who knows the secret could). Oftentimes the API key and the secret are ‘complementary’.

        Unless we’re talking about oAuth-based authentication / authorization – which is a slightly different beast and a little more of a pain to work with.

        Not sure if it will help – but do read a little about ‘hashing’, MD5 and message digests. It’s very frequently used for API requests authentication (in various forms).

      • Hello Marek!

        Thanks for clearing up the API_secret. I was mixing it up with oAuth based authentication. I will also add hasing, MD5 encryption and message digests to my reading this weekend. As always, I appreciate your guidance.

        Have a wonderful weekend.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s