The culture of Rails is program by example, because they want you to understand the happy path first. That's why you start out by generating a "working", if essentially do-nothing, Rails application, every time you do
rails new MyApp.
If you do things "the Rails way", the idea is that most typical business problems are applications of the happy path. You may not remember this, but starting from the API docs in Java was not the best way to get started either, because you had to guess what you needed to know. So you probably started from some books and tutorials and spent a lot of frustrated nights trying to make sense of what was considered idiomatic.
When you have a problem for which the happy path creates unneeded friction, the Ruby On Rails documentation at http://api.rubyonrails.org/ will help you with what you need. However, the conventions in Ruby documentation are different than Java's, so it will take some time and effort to adjust to the format of this kind of documentation. On the upside, most of the time the contributors have written excellent introductory topics on the modules and classes that are really core to understanding Rails, and those are inline with the documentation. If you don't get something, chances are that you are either looking at the wrong part of the documentation. If the documentation is still confusing, step back and figure out whether the issue is that you don't understand something about how Ruby works (and there are excellent books on that), or whether it's something unique to Rails, and try to attack that problem first.
Ruby for Rails (now a bit dated) and The Well Grounded Rubyist will help you understand Ruby better. The Rails Way is deeper than the Program-by-example approach in Agile Web Development with Ruby on Rails, and moves from quick dives into each of the major components of Rails into deeper reference material on Rails (and is reasonably up-to-date as of this writing).