I understand that a Controller in an MVC framework acts as an interface between a Model and a View. If my backend is an API (doesn't have any Views), is the Controller not needed? If so, should I put my CRUD operations in the Model?
If you're just planning on performing REST operations w/out needing to return Views -- you should certainly look into WEB Api controllers. Web Api allows you to define the REST operations as the operation names themselves, e.g.
public void Post { ExampleModel model}
public void Put { AnotherModel model }
public Something Get { string id }
public void Merge { string name, int age }
The other added benefit of using Web Api is that your values passed into the methods are automatically mapped upon calling the method and returning POCOs.
I consider an API to be a bit like a User Interface. It is a media, in the border of your system, that allows to interact (indirectly) with the system and its data.
The data access is generally one of the mecanisms at the heart of your system. Any Interface Layer (UI nor WS) should be able to interact directly with the Data Layer.
This is the role of the Service Layer. The Service Layer interacts with the Data Layer and the other services. This is the one that owns the business logic.
In the case of an API (that is something you expose to the world, out of your system), its responsability is to assert that the input/output data are valid, and to make some conversions (for example, if the input data are String, to convert it as Number, Boolean or whatever).
So, I think that in your case, you should put your CRUD treatments in some lightweight applicative or domain service, and then to call it in your API services.