I´m mainly a coder but for a project I've got to do some more with RoR. I've been working with RoR for some projects but mainly on the front-end side. I understand it a basic level, but for this project I have to dive in the deep.
What I want to create is an app where a user can search for movies and add them to their account. I want to use theMovieDb api for this, but I can't find a screencast or tutorial that shows the beginning of how to connect your app with someone else's api. So I was hoping the StackOverflow people could point me in the right direction.
This is kind of a big question, but it seems you have two parts here. First is how to make a request from inside your application. The second is how to interact with an API.
I've set up somethings similar where I had to make API requests from inside a controller using Net::HTTP. The answer to this question helped a lot. From inside the controller, I processed the request response as needed, i.e. putting it into a relational database, or displaying it to the user.
How make a HTTP request using Ruby on Rails?
The second part about interacting with the database. The movie database API is described at
http://docs.themoviedb.apiary.io/reference
You need to reference this API documenation. The first thing, for instance, = is they require you to get an API key for instance. You will also need to be aware that they limit the rate at which you can make requests. Without knowing more specifics its hard to give more detail about how to construct the queries.
Hope this helps.
Related
I know I'm going to get downvotes for even asking but I honestly have no clue how to do this and any assistance would be appreciated as I have never done this.
I have a client that migrated their blog to HubSpot and would like to have their blog posts displayed on their website. So how do I connect to HubSpot's API to display the blog in their website that I have in a Rails app?
Do I create MVC just for Blog API? Where do I put the URL to connect to?
If you want to connect to an other API the best way to do this is to create service objects. These are plain old Ruby objects (aka PORO) that represent the API as a Ruby object. You are free to use any location you want, but I would stick them in lib/services or app/services. If the provided API uses the Rails (REST) standards than you might be able to use ActiveResource.
You could also look for gems that provide these service objects. A quick RubyGem search finds multiple (unofficial) gems. From witch hubspot-ruby seems the most used and active.
If the gems don't do what you want you could look through the code to find some inspiration and create you own objects. Another option is to fork a project and add the functionality you want.
Here is a link to answer the broader question you're asking: What is the proper "Rails Way" to consume a RESTful web service on another domain?
I've come across two scenarios with regards to creating a REST API in Rails and I wonder which one is preferred. Usually
if you know that you're required to have a REST API for your application at start. Does it make sense to have it in a namespace and thereby duplicating the controller logic?
I've seen examples where people have an application already and later figure they need to extend and offer a REST API. The approach to this has been to create new routes with namespacein routes.rb and controllers/api/whatever.... This still yields duplicate code though, but might be more sensible approach. The difference being a stateless machine for the REST API calls.
Can anyone elaborate on the preferred approach, thanks.
If you create a Rails application, and following the usual conventions, you basically end up with a REST API. Unless you are talking about a more specific meaning of the term (which I am not aware of), "REST API" is more a bunch of general characteristics of the API (i.e., things like statelessness, resource-based URIs if using HTTP, etc.).
So to turn the question right back to you: which case are you thinking about where a (conventional) Rails application is not by extension trivially a REST API?
I'm working on a web app with the client side made in Angular and the backend made in Ruby on Rails. The app will need to show a list of articles (dynamically generated data).
Here’s what I’m pondering about.
Online tutorials on building Angular apps coupled with Ruby on Rails are based on the following model of interactions between the client and the server. First, the client sends a request to the server, in response to which the server will send all the building blocks required to start up Angular, and then Angular will request all the missing data from the server. In my case, first Angular starts up then it requests a list of articles.
That's two request-response cycles, as illustrated by the following diagram.
What if, on the other hand, the server will during the very first response send the data necessary to display the initial view? Like, in my case, what if the first response also contained the first batch of articles to be somehow imported into Angular? Then there will be only one request-response cycle as shown on the following schematic:
Is this a good idea or a terrible one? And if it is not absolutely terrible, what is the way to import Rails’ instance variables (e.g. the first batch of articles sent as #articles) into Angular while it starts up?
(I found similar questions discussed — though very briefly and without any consensus reached — here and here.)
=======================
UPDATE:
OK, here is another StackOverflow discussion about this:
How to bootstrap data as it it were fetched by a $resource service in Angular.js
Is this a good idea or a terrible one?
I'd argue it's a Good Idea. It will improve your app's performance and requires minimally invasive changes. You could even configure your Angular app to conditionally make the requests in case the data isn't available on page load for some reason.
The Gon gem makes it trivial to use your controller instance vars in your views (as JS).
I'm new to the rails world and am trying to build a app to simply allow me to search things on Amazon and such sites based on the users input.
I've done a little reasearch and it seems the httparty gem is a good place to start? The documents ive found so far though are not the best. They don't really give me a lot of information (where to put the code etc).
Are there any existing tutorials out there or code examples that I can either use or take a look at to give me a better idea of how this thing works?
I'm working on an app like this right now, so let me offer a few thoughts.
First, if you're a complete newcomer to Rails, then as a first step I'd suggest taking a parallel approach to the problem, with two tracks:
Learn about Rails
Learn about how to interact with an API (make requests and parse responses) in Ruby
These are two separate problems, and although you may end up implementing them together, it's best to think about them in isolation first.
For the first one, I'd suggest writing a couple simple apps first to get a feel for how things work. Even only a simple app will require a certain amount of user interaction, possibly saving records to the DB, etc., problems that are separate from consuming data from an API. There are an endless number of tutorials out there on Rails, but just to mention one, you might try Michael Harti's Learn Web Development with Rails as a starting point.
The second point, consuming API data, is distinct from the problems of designing the app itself. To learn more about this aspect of the problem, I'd suggest using a popular API client gem like (as you mentioned) HTTParty, which I use myself. Rather than immediately try to use the HTTParty methods in a Rails app, as an exercise I'd suggest playing around a bit in a console (irb). If you install the gem (gem install httparty) you can then require it (require 'httparty') from the console and immediately make requests and parse responses from the APIs.
E.g.:
irb(main):001:0> require 'httparty'
=> true
irb(main):002:0> response = HTTParty.get('http://twitter.com/statuses/public_timeline.json')
=> ...
Once you've got a bit more familiar with Rails and with accessing an API in ruby, then you could move on to actually building the app itself. Depending on how complex your requests to the API(s) are going to be, you have a few options as to how to structure your API requests in your Rails app:
Make the requests part of the Rails app itself, directly from controller actions. This is really only okay if you are only going to support a very limited number of request types (e.g. simple search) on a limited number of services. Anything more complex and your controller will get fat, which is a no-no in MVC frameworks.
Create a separate ruby class (usually called an API wrapper) to group together methods for making requests and parsing responses from the API. With a gem like HTTParty you can do this just by adding a line include HTTParty in the class, which adds the module to the class. There are lots of examples out there on how to do this, here is one.
Use a dedicated gem for accessing specific APIs, or create one (or more) yourself. There are gems for most popular services, e.g. Twitter, Linkedin, Flickr, etc. See this list of API client gems for more. This takes away a lot of the pain of interacting with an API, but will only work for a subset of all services.
You mention you're thinking of using HTTParty, which I can recommend as I am using it myself. There are alternatives such as Faraday (see this list of HTTP clients for more), but I find for most tasks HTTParty will do fine. The documentation may be a bit sparse, but there are a bunch of examples that you can work from.
Hope that helps!
My friend has setting up a database for a Ragnarok Online server, and he wants me to code the relative website, which is going to use some of that data (and obviously, i'll have to add tables for the news system, website accounts, etc). Since i'm learning RoR i was going to do it that way.
I have a few "best practice" questions related to this :
Should I create a different database for the website, since it's going to have its particular data alongside the game data ? (i already have a few clues to link multiple databases with Rails, but that seems too much of a hassle for what it is).
If not, do i have to create Model/Controller for each of the tables composing the database, despite the fact that i'm not going to use 90% of it ? Or just the ones that i need ?
An example of this problem : the game database has its own "user" table, but i have to have another "user" table for the website, and do some Joins between those two. So, what's the best practice here ?
Uhm, best practice is not making your own user table. This will cause you much pain. Best practice? Use an API. Expose the game's database in some way to your website, and fetch that info with external requests in your web application.
The reason why making a second user table is a hassle:
1) You'll constantly have to update it, pulling data from the original
to keep it up-to-date.
And I mean furthermore, you're gonna have to create a CRON job or something pulling data from that original table to keep it up to date. Yuck. Also what if that CRON job makes a mistake? (It will)
2) It's almost inevitable that there will be inconsistencies if two
separate tables are maintained. Are you sure your web application is
really fail-proof?
Update:
What you're gonna need is essentially a second Rails application that acts as a REST API for that database. For a good idea of what REST is, I'd read through this to get you started: http://tomayko.com/writings/rest-to-my-wife
Once you have a good understanding of that, start making your app, and test if it's working by using tools like cURL to send requests to your API.
Once you have that done, I'd take a look into the Ruby rest-client gem like Nobita mentioned. This is what you're going to use from your web application to request information from your API application.
Just let me note, I think this would be a terrible first Rails project, unless you're already really well versed in other web development tools, preferably MVC frameworks.