I am developing a Rails application which will need frequent access to public APIs, and I am not sure what is best way to put external API (SOAP/WSDL) code in Rails application, what about model thingy, how we can manage that? Any ideas, comments?
The current contenders for "best" library for consuming External SOAP services seems to be either Savon or Handsoap. There is a comparison between the two here
I can't comment on handsoap as I haven't used it by I am happy with Savon which is working well for me.
In terms of Application structure then I would create a folder under lib for the interface named after the external entity and then store files under there using the namespacing features of rails.
So an example I have an external interface to a system called Sentinel. So I have RAILS_ROOT/lib/sentinel and then all classes within that folder are declared within a Sentinel module.
The first thing to do would be to see if there are any gems for the API's you want to interface with. Write a small wrapper class for the gem or just include it and use it where needed.
If you're looking to talk to a REST service, I would suggest the rest-client gem. If you want to do something completely custom you could make use of Jon Nunemaker's HTTParty. Nokogiri, an XML parser gem is useful for consuming XML-based services as well.
Related
Just been researching about this approach and never seem to find a concrete answer online.
I'm seriously curious about the chances of only consuming the API for activeadmin. Then using the JSON objects in React or Angular with a custom UI.
Is this doable?
Absolutely! See https://blog.heroku.com/a-rock-solid-modern-web-stack
For notes on ActiveAdmin vs Rails Admin and other alternatives see https://github.com/activeadmin/activeadmin/wiki/Alternatives
I've also used both Grape and GraphQL in different places, one for performance, the other for flexibility, both reasonable choices.
In theory it is possible since you would just be using the endpoints provided but I think it would be far a far better design choice to choose another API framework gem like grape. One of my complaints with ActiveAdmin has always been that it is not very flexible and you can quickly run into limitations which means that you can't add features that you want to. IMHO you would be digging a pit instead of opening possibilities.
Personally I really like GraphQL (which would be another option) and the graphql-ruby gem is easy to set up and start making highly reusable components that can be leveraged from anywhere admin or frontend.
I am creating a Rails app that will use quite a few external APIs such as SalesForce, FolderGrid(like Dropbox) etc., which would all sync to my database. I've never worked with external api calls so I created a few basic Ruby scripts with scattered methods to test the call to those resources. Now I would like to implement them with my full Rails app.
So far, I started off by creating a directory in my /lib folder for holding the api call modules/classes..
/lib/apis/foldergrid.rb
Now I'm not sure what the best approach would be towards organizing the code. In my standalone Ruby scripts, I have methods for authenticating, creating a folder, auditing files, downloading files etc.
What should be in a Module? Do I even need a Module? What should be in a class? How do I make sure I can use these methods in my models and controllers where needed? Is there a best practices concerning external APIs?
Any resources, links, and/or deeper understanding is highly appreciated.
I have an app that does this too (pulls data from multiple APIs) so I can tell you what I would did (or in some cases what I would do now if I was to start over).
Data Storage
First off if you are already persisting the data pulled from those into a Rails app, then you will have models representing the data themselves. So that's what you would refer to in your controllers unless your controller is in charge of calling the APIs.
Use Gems where possible
Second make sure to leverage existing gems that existing for the APIs so you're not recreating the wheel of authentication, parsing the JSON to and from the app, etc. For example: there is a rest-force gem for salesforce.
Use Ruby Objects in Lib for mapping between your models and API responses
Third, I would make the classes that map data in between API responses and your models into "Plain old ruby objects" and store them in a lib/apis folder (no need in these cases to store in a module, yet IMHO). They might end up very functional and in the case of mapping data, that is ok.
APIs without existing Gems
In those cases, I would definitely keep them in one or more classes under a module, in their own folder in lib. That way you can parse them out if needed as a Gem (or if you to take the time make them a Gem to start with, I'm sure others could benefit). I just started down this road myself this week using Infoconnect's API which didn't have a Gem (or any code samples in any language). But I'm not very far along.
If needed, create service objects for code in between V and C (view and controllers)
If you do end up needing to do anything to interact with users for the API information or anything that calls those request, I would put those in service objects so your code doesn't get bloated in the view or controller.
What should be in a Module?
A module should contain code that is shared by different classes, or it can be added to a single class.
Do I even need a Module?
No, you can achieve the same thing with inheritance. If there is no code to share, then you probably don't need a module.
How do I make sure I can use these methods in my models and controllers where needed?
You can access them using the class from within a controller:
SalesForceAPI.get_data
"Module or class?" is an age-old question in Ruby, and any other language that supports both.
I would encapsulate the functionality for each API in a class. For example, you can have a SalesForceAPI class. Then, if you need to share functionality between the classes for authenticating, creating a folder, auditing files, or downloading files, you can create an API class.
Each of the classes that needs access to the API class would inherit from it:
SalesForceAPI < API
You can achieve the same thing by creating an API module, and mixing it into the other classes. In this case, it's largely a matter of preference, because either solution is good.
FWIW, I don't know if there would be much shared functionality for authenticating, creating a folder, auditing files, or downloading files, because each API can work quite differently. However, if they are REST API's then you may create some REST helper methods and put them in the API class.
A great, easy to understand, and complete resource on the topic is Practical Object Oriented Design Ruby.
I have an application that has some model and services. I need those entities from another app from another directory. How can I share them? I don't want to use public API or REST interface via the internet, but just call services in local. Can I configure it with Rack?
If you want to share the code then the rails way is to make they as gems and use them in your applications.
If you are using rails > 3 , best way is to do it via rails engines, Its easy to learn and more elegant.
But simplest and not recommended way is to have your methods as ruby modules/classes and use then in your each project (by having them in you lib directory or some were)
HTH
I am running Ruby on Rails 3 and I would like to create an application APP1 that acts as a Web Service. Then create another RoR application APP2 that can communicate (send/get information) with APP1 using the OAuth protocol.
What I have to do to start (I am not expert about programming in those topics but I read a lot and I know how they conceptually\theoretically works)? Is it good to think to implement my custom code or maybe it is better to use plugin or gem? Why?
If it is possible, can you write a TODO list and steps to accomplish what I aim?
And, more important, can you suggest me some useful (awesome) resources (like books, blog posts, ...) about creating RoR Web Services?
Assuming you get to decide what kind of Web Service you want, and a RESTful XML Web Service is an acceptable choice, then Rails applications practically do this by default. When you generate scaffolding code, your controller will actually be ready to interface with as a RESTful Web Service.
Of course, that's not everything you need to know and do, but the subject seems to be covered very well by the following series of articles...
http://css.dzone.com/news/rest-with-rails-part-1
http://css.dzone.com/news/rest-with-rails-part-2-serving
http://css.dzone.com/news/rest-with-rails-part-iii-using
Unfortunately, there seem to be some JavaScript errors on those pages, but they're still usable.
I know this doesn't answer the OAuth part of your question, but this article ( http://stakeventures.com/articles/2009/07/21/consuming-oauth-intelligently-in-rails ) apears to have some useful information on that subject. Note that the info here is slightly out of date if you'll be using Rails 3 because you'll want to list the gems in your Gemfile and run bundle install rather than adding config.gem ... lines to your environment.rb file.
In situation, when I need a webservice client, which will be used by some action controllers, how should it be implemented? As it will have some constant values (addres, parameters names) and session key, refreshed every 30 minutes, I guess model stored in database isn't the best solution. What is the best practice?
Built the web service consumer as a library and place it in your /lib directory.
I would also recommend HTTParty for very simple consumption of web services. You could easily build a library to handle the task, a simple class with a few methods and toss it in your /lib directory and be on your way.
Good luck!
Rails 1.x used to have "actionwebservices" builtin but it has been removed from Rails 2.x. The last time I did this was to build an SSO server implemented as classes using XML-RPC. The code is not public unfortunately (done internally for my employer) but was under 1k LOC incl. comments... Plain Ruby.
Now, I'd probably use a lightweight framework like Sinatra or an equivalent.