The short answer is “probably”.
The long answer is “it depends”.
The even longer answer is “it depends what you mean”.
Fast-forward ten years and web-sites and web-apps are still important, but the world has moved on. When we talk about “the client”, what do we mean? Phones, tablets, computers, watches, fridges, shoes … they all (apparently) need connectivity nowadays.
So, your app probably does need an API. Or will do one day, if it’s to survive in the modern world.
But you could start with a traditional style Rails app, rendering HTML on the server (as your .html.erb templates) and sending it to the client; and add in an API to replicate those same functions for non-browser clients. In fact, that’s what my current project is doing (and some day soon I’ll show you how I ensure that the two stay in sync and I can easily share code between the two access methods). The API is being written using Grape with Grape Entities for publishing JSON and XML, with the HTML using ERB and Turbolinks.
Or you could go the whole hog and build a pure API, then one or more separate front-ends, maybe using Angular or Ember for your browser client. And that’s what I did for my last project (although I used KnockoutJS plus my own library as I like Knockout’s simplicity). The API was written using pure Rails and the JBuilder library for publishing JSON and the HTML is mainly static (although generated from ERBs).
The older app is probably better. It has nice transitions as things happen on screen, it responds really quickly, customers are really impressed with how it works. And conceptually the code is a lot cleaner in a lot of places as UI factors don’t ever impinge upon the back-end code. But it’s harder to track down bugs in production (as so much happens on the client where there’s no logging) and the full-stack test suite takes nearly an hour to run.
But in the long-term, if you’re not working on a throw-away project, the chances are you will need alternative clients. And for alternative clients you will need an API. Just remember, it doesn’t mean you need to throw away your traditional Rails knowledge, so you can start adding the API in as and when you need it.