Working with APIs in RoR [closed] - ruby-on-rails

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
This seems naive to ask, but seriously I have not seen a resource which explains how to work with an API. The basics. More specifically the procedure to start-up with an API.
There are loads of things in the docs. But how to get it working with an RoR app. Like what variables to put in the db, in the attr-accessible. Or is it even required.
Then parsing it in models. Managing from the controllers and displaying/calling in the view. Dont get me wrong, I do know about RoR, I have made apps, but with API, seems confusing. Need to know all the basics.
Is there any resource which teaches to work with an API.
For my scenario, I want to work with a travel API. What should be the first procedure(after getting the API key).

Answer 1

How you work with an API is largely defined by how that API exposes itself, and what libraries of code you have to deal with it.
Many APIs are presented as HTTP endpoints that you can use CURL, OpenURI, HTTParty or something like that to consume the resource, or deal with the data sent to you, often as JSON or XML.
Here is a list of some of the more popular Ruby HTTP API client libraries at the Ruby-Toolbox.
Pick one of these and write some code that gets an endpoint of that API, then use that data to do whatever you need. Treat the API somewhat like a database.
Codeschool has a cool course that you can start with and do the first few levels for free here:
Surviving APIs with Rails

Answer 2

First, before choosing to work with an API or not, I highly suggest to try to work with REST API since these kind usually adhere to the same structure (there is even a book on REST API) and then you know what to expect.
Lets take a fictional Movie DB REST API example
so REST API is all about resources. Every movie can be created read, updating or deleted (CRUD).
so you know that you have these commands in your disposal - if you want to get a movie in your app you would use the read command that the api supplies. It usually looks like GET /movie/13 (HTTP GET request)
so in your app you would have to insert that line whereever you want it (perhaps in some panel where the user search for a movie and you access the movie DB to get the details of it
so you would have a
def movie_panel
#some stuff
#movie = MovieDB::get(movie_name)
end
so now you have the movie.. now what? parsing it is indeed annoying. luckly most API have gems you can use so they did the parsing for you. Here I used the fake gem MovieDB but if there is no gem you need to query the api yourself, which in this case I advise you to build your own gem, or atleast have a module with some classes and method to make life easier for you. something like
module MovieDB
class Movie
attr_accesor :name, :year, etc...
def initialize(movie_params)
#initizalize the movie attributes from a given movie params
#name = movie_params["name"]
etc..
end
end
end
so in this case you would have your own API wrapper to use. So once you are given the movie params from the external API you can do MovieDB::Movie.new(movie_params) and that will create a movie object that has method (that you need to write) for the functionality that you need in your code.
Inside that module you can handle everything about that API and abstract all that from the core of your app.
so to sum up -
REST API - easy, predictable, managable
non/rest api - make sure there is proper documentation
use what the api gives you as a resource, and ask yourself questions - what do I want from the API? what will I do with the resources (such as a movie, or a facebook page, or a tweet)? Does the API docs say its capable of doing what you want to do with the resource?
as documentation goes, you need to read it to understand what to do. No all docs are clear and not everything is clear on the first reading because you don't know where to start. So start at the beginning - why do you want to API? What does the API promise to do? You need to authenticate? Is there a tutorial? Has someone already made a gem for the API?
take some famous API's and not-so famous API as an example.
Facebook Graph API is very well documented. You know exactly what you get from each command and what to expect. You don't need to write it yourself, since Koala gem have you covered. On the other hand of the API rainbow, lies a Pinterest API, which you might wonder what's it for.. No one knows, because its barely useable, you need to get access to it, and even then its very limited. So if you want to plung in to the Pinterest API, make sure you understand what it gives you and what it doesn't (hint - it doesn't). That's true for every API where it has good docs or bad docs.
Good luck and might I suggest to read http://shop.oreilly.com/product/0636920028468.do and maybe this as well - https://github.com/interagent/http-api-design
Update with the actual API
ok so the api http://www.wego.com/api/flights/docs you wanted is documented quite well
the first thing it says is to get the API rate check
GET http://www.wego.com/api/flights/usage.html?format=json&apiKey=testAPIKey
so right here you can begin to structure your code. You need to save the apiKey somewhere and have a url prefilled with http://www.wego.com/api/flights/usage.html and the parameters are the format and the apiKey
you can create a helper method that does that.
def check_rate(format, apiKey)
...
end
inside you will need to send a request and get the response and parse it something like
uri = URI.parse(#url)
https = Net::HTTP.new(uri.host,uri.port)
req = Net::HTTP::Get.new(uri.path)
req.body = ["format=" + #format, "apiKey=" + #apikey]
res = https.request(req)
and that takes you forward one step. Take the result and parse it. Best in this case is to create a class for this kind of response and add methods such as rate_ok? and such. Basically a Class for each response and instantiate a class per response. The constructor of the class would parse the response and expose whatever attributes you need