I have 2 different Rails application and I want these apps to send and receive information via an API. What is the correct way to do this?
I was trying to use this resource but I don't quite understand it: http://api.rubyonrails.org/
(I am not sure how to make the call for the different methods. Some methods show an URL which I guess I wouldn't have too much problem implementing, but what if the application is within the same server, what would be the correct way to call a corresponding API method.)
Is there a recommended beginners resource out there?
Thanks.
api.rubyonrails.org is Ruby on Rails documentation, so this is API of RoR. What you want is external HTTP, probably REST and probably JSON API.
There are many resources on building REST API's. In general you have to prepare some endpoints that application can send request to and handle responses.
Take a look i.e. on railscast about using active model serializers. This would be the part where you give other application endpoints to get or change data.
Normally you would stop here because in most cases you set API for other applications (like mobile or javascript applications). But in your case you will need something to send requests. There are many gems that allow that, but I find Faraday gem most useful.
Related
I would like to create my own web chatbot and i like to integrate my app with wit.ai for natural language classification.I need to know how to integrate wit.ai service(through api call) with my application(any language in backend).i am using C# in front end.I have gone through the integration part Which posted in wit.ai website.But i don't know how to connect it .Could anyone send me a integration details little briefly
I think the short answer is its similar to how you would call any other APIs from your application server components. Wit exposes multiple APIs like message, speech and converse which you can call by passing the Authorization token and other payloads and make use of the API response in your application.
You can use message API if you are only interested in extracting
intent and other atributes of the sententense
Use speech for building voice based application and
Converse if you want to build a little more smarter app. Currently you can only pass text for converse APIs.Hoping they will introduce voice option for this soon.
Now to make things simpler, they have also provided SDKs in various languages like node-wit, pywit etc. So if you want to build your server side logic using on nodejs or python you can use these SDKs. The advantage is that you dont have to manage raw APIs calls and instead it is all managed by SDK. Also, other big advantage is that you can make use of runActions method which encapsulates converse API and make things simpler. If you want to build in nodejs then the messenger example is a good starting point. You can borrow all this logic/concept in your app and replace FB related calls etc with your custom bot. For Python you can look at the below link
https://github.com/wit-ai/pywit/pull/55
Also, you can explore the options like using other frameworks like botkit if you plan to integrate wit with other chatbots like FB messenger or slackbot as these frameworks provide more flexibility and ability to easily switch to different chatbots in future. But they don't seem to properly support the converse API of wit.
You are specifically looking for integration details. Since you are using c# for frontend app, natuarally the best option would be to use c# for backend as well. In which case you will be left with directly calling wit APIs from your backend as I think there are no SDKs in c#. If you want to make use of SDK in node or python etc then you will have to build a rest based backend (for example) which can be invoked from your c# application. I am currently working on a nodejs app and integrating it with wit using node-wit. I can share some code once its ready but i dont know when I will be able to finish it. For bootstrapping my application I have used this node application. If you have some understanding of node then you can look at the /server/controllers logic. Similar to this application I have built a witController which uses runAction to interact with wit and I am calling this from front-end when user submits a message to your bot. The biggest challenge in runAction is to figure-out a way to send back the wit response to your front-end and get follow up response from user. Wit sends the response in Send method as you can see in the node-wit's messanger example.
Hope this helps!
I have a web app implemented in Ruby on Rails 4, need an Android native app for it, I am really new to mobile development.
I am a bit confused as to what the mobile-web architecture should look like in this case. I've done some research online, there seems to be a few ways of doing this, but I still have some questions that I haven't been able to find answers for. Thanks in advance for all pointers.
1) do I really need a separate API for the mobile app? what are the issues in using my Rails app's existing controllers with respond_to format.json?
2) I've seen some online examples that suggest using an separate API namespace in the Rails app to serve mobile requests, e.g class Api::ApiController < ActionController::Base for the new controller, then add namespace :api do in routes.rb. With this approach, doesn't it imply that I'll need to duplicate quite a bit of my controller functionality in this new namespace just for mobile?
3) Regarding authentication, many examples suggest using token authentication, is the built-in Rails sessions management framework not good enough for mobile apps? or is it because session cookies work completely differently in a mobile app?
Appreciate your time.
It is not necessary, but it is, like you said, considered a best practice.
1+2) Having same controllers with respond_to/respond_with logic is a nice idea at first sight. But, from my experience, I can say, there always comes a day where API code start to differ with HTML client code. The mobile client might have a different UI and it is just natural that it will expect to consume your data another way as your web client does. The web client is specialized to one use case where an API should be more generic allowing multiple consuming ways.
The second issue that will arise is the fact that you cannot rely on your mobile users to always have the latest app version where with a webapp you can. So for the HTML app you can easily introduce non-compatible changes because you are delivering a proper client right within where for the mobile API breaking the API is at least concerning. Perhaps, you will want to maintain a backwards compatibility which will make your all purpose controllers ugly as hell. And without a proper api/v1 namespace you even can't have two different API versions at the same time.
You can avoid duplication of your logic by keeping your controllers very skinny and move the logic out into models (Service Objects are models too, not only Active Records).
3) Your mobile HTTP lib will to a high probability have a proper automatic cookie management. Having token based authentication is just again a best practice. If it is just a token vs session_id within cookie, there will be not much win. I can only think that it will be automatically secure against CSRF attack and you can disable this protection entirely for the API because your website users won't be allowed to consume the API, just by logging in to the site (an additional benefit perhaps). With session based authentication you will have to generate a CSRF token on first API request and set it within X-CSRF-Token cookie.
The big advantage of token based authentication is that it is extendable to more security, like introducing expire tokens, HMAC tokens etc, whereby session authentication is not.
See Using Sessions vs Tokens for API authentication
I would also encourage you to look at json:api. It comes from the creators of ember.js, who have thought about minifying decisions to take, when building APIs. Another interesting thing is an active_model_serializers gem. An intro to it is given within Rails: The Next Five Years by Yehuda Katz
I am trying to create a REST API for my web service.
I want to make the users of the API able to initiate a new request with my service. This involves uploading one or two zip files along with some other parameters.
How can I make this all combined into one request? Or is it better to do it multiple requests somehow?
I don't have a lot of familiarity with making REST APIs so I don't know how people usually do it.
I'm using PHP for my site if that matters.
To do this, you'd need your client to upload in mime/multipart format. I don't know PHP, but I'm sure there's a library out there that will support receiving/parsing the multipart messages you get.
As for whether it's a good idea .. If initiating the request is the creation of a single resource, it's not unreasonable to accept mime/multipart. If the parts being sent are themselves full-fledged resources, it would probably be better to make the client send them up separately, and reference them in the initiation request. Also note that mime/multipart is going to be a bit harder for your clients to deal with than simple requests.
This post seems to be related to what you're trying to accomplish.
Recline.js seems a great tool to display data on grids, maps, etc.
I'd like to use the grid views, but to be able to save what is displayed to the user on a database. I'm currently using rails for this project.
In the docs, they say how to code a backend to integrate with it (http://okfnlabs.org/recline/docs/backends.html) but i wonder if there's already someone working on it ( I couldn't find it on the web)
Thanks
The Backend object in Recline.js a javascript component that talks to a data source of some kind, typically a web service. The Backend component talks to the interface of that web service, and it doesn't care whether it be programmed in Ruby, COBOL or Java, as long as it knows where to get and send the data, and in what format.
So in short there isn't, and can't really be a ready Rails backend, because the implementation depends more on the specifics of your application -- how to map the data in your database (MySQL?) to a service API Recline can understand, and vice versa.
You can use SOLR with Rails, so I dont know why you couldn't utilize the Recline.js SOLR functionality to search your rails data.
As a preface to this question: I am brand new to Rails development (and web-development in general), and some of my concerns may be unfounded, so any feedback would be very helpful.
I am attempting to make a Rails application that plugs into a RESTful API. I have been trying to determine the best way to go about this, and from what I understand, its narrowed down to making my own model from the ground up, utilizing ActiveModel, or utilizing ActiveResource.
It is unclear to me the advantages/disadvantages of each, and to be frank, I do not yet fully understand the difference between ActiveModel and ActiveResource. Can somebody provide me with insight regarding these three options and what makes the most 'sense' in a ror context? Thanks!
The best answer wouldn't just say "Use ActiveModel", or "Use ActiveResource" with instructions on doing so, however that would be helpful as well. I would really appreciate an answer explaining why I should use that thing, etc.
A few constraints I am dealing with are that I need to be using a key when I call the API, and a good number of the API calls will contain additional parameters.
So the key to choosing which package to use here is whether:
You are RETRIEVING data from the web API and want to
store/manipulate on YOUR server, or
You are MANIPULATING data via the web API and don't intend on storing anything on your server.
If #1, you'll need ActiveRecord, as it's Rails' package for manipulation and storage of data on your Postgres/MySQL/etc database.
If #2, you can use ActiveResource exclusively, which will let you retrieve data from the web API, work with it at runtime, and then make changes by posting back to the web API.
Many applications though, will often use both of these packages. ActiveResource to grab data very easily, and then applying it to ActiveRecord models (like User, or Location, etc) which you can use locally without having to grab data from the API over and over again.
To give you an example, for a service I was working on I grabbed Geolocation data from a public source (looking up coordinates for zipcodes), I then saved that data to local Location objects using ActiveRecord so I could look them up repeatedly without the delay of the Web API call. (if you're smart, you'll refresh this data from the web API from time to time)
Determining whether ActiveResource will work for you
Do the service requests conform to the documentation protocol? Look at the Expects a response of block in the Find method, for example. If so, you might be good to go without extra work.
Note: The documentation is a little out of sync with the changelog — as of Rails 3.1:
The default format has been changed to JSON for all requests. If you want to continue to use XML you will need to set self.format = :xml in the class. eg.
Also, ActiveResource has been removed entirely from the Rails 4.0 branch, so if you're looking forward to starting a new rails application and want the latest and greatest, this isn't an option at all — but all hope is not lost, there are plenty of gems that make interacting with RESTful interfaces simpler, like Faraday (full disclosure: I have not used faraday myself so can really comment on its efficacy, but I located it here, and there are a number of other options.
Note (from the same link above): Active Resource is built on a standard XML format for requesting and submitting resources over HTTP. It mirrors the RESTful routing built into Action Controller but will also work with any other REST service that properly implements the protocol. REST uses HTTP, but unlike “typical” web applications, it makes use of all the verbs available in the HTTP specification.
If the answer to the above is no (it does not conform) you'll need to write a wrapper class, see Facebooker for an example of how this is done in an actively maintained gem.
References:
Great tutorial on ActiveResource
Getting started with ActiveRecord
Keep in mind if you're just starting web development, you'll need to understand database and model basics too — you have your work cut out for you. :)
I will give it a try, and hopefully others will come and correct (or add) to it, so a better picture will exist ...
I see the following main differences between the two:
ActiceResource provides an interface to a resource that is (normally) accessible remotely by a (Rails) RESTful API. It is not stored kept locally, but read, updated, created and deleted by the API only. As Ryan Bates states it: "ActiveResource allows you to easily communicate between multiple Rails applications."
ActiveRecord (or nowadays ActiveModel) stores its record (or model) in a database locally, and allows others to access it remotely by a web interface for
Showing pages
Returning JSON maps or
Returning XML structures
Advantages and Disadvantages
To use ActiveResource, you have to check that your local Rails app can speak to the remote application, so that the RESTful API is compatible.
If both options are free to choose, here are some arguments:
ActiveResource will normally more expensive (calling a remote system costs at least more time) than ActiveModel.
ActiveModel will cost your own resources (setup of database at least), but this is normally not a burden.
So at the end, it depends on if you want to store something (ActiveModel) or only retrieve something (ActiveResource), which means you will use ActiveResource and (perhaps) ActiveMiodel.