You will see varying practice, with some more traditionally minded DBAs maybe saying at the extreme 'never let developers write SQL, wrap everything in stored procedures'. My answer, for the environments I'm currently used to, is 'yes, but...'. Here are some of the reasons (which in some ways are really the same reason):
- Agile development methodologies often like to take 'vertical' slices - a single developer develops a complete piece of functionality with end-user value. This enables the developer to understand the purpose and value of what he's doing (and relate it to what a customer wants), to ensure that the code he writes fits that purpose, to shorten feedback loops, to know better when the code is actually complete, etc. Potentially it can be more motivating, too - motivation partly depends on visible individual impact on outcomes that matter. All of these things apply to the database as much as any other layer.
- To understand the application behaviour and its performance you have to consider the code and the database together. To design a database structure or query you have to understand how it's used and to write an application using it you have to understand how the database will behave. Compartmentalising knowledge of these things is a problem.
- Creating a boundary between SQL writers and developers means there's more friction to getting one side or the other changed. Need a new query, but you can do it less well by using existing queries, fetching too much and doing a join in your code? Looks like a field should have a foreign key constraint or lose an index, but you know nothing about whether the code can cope? It's tempting to take the path which doesn't involve having to ask, explain and wait (and maybe overcome resistance).
As a worst case of the first and last together you can have DBAs holding up important user-visible features they have no incentive to care about because it spoils their vision of how the database should be (or simply distracts them from something more interesting). You create misaligned goals, conflict and power struggles.
The 'but' is that you need the appropriate skills, tests, code reviews, knowledge of individual team members, design oversight, understanding of requirements and so on within your team. Not everyone will understand the locking behaviour or performance characteristics of your database, for example, but you should be able to handle this. The good news is that you already need all of these things for the rest of your code anyway.
As for your particular case, it sounds as though your API and database structure could be highly coupled. Why can you not simply leave the password hash (I really hope it's a hash) out of your ORM's definitions? Or make it a private field and add a 'verify password' method? Or leave it out of the objects that are serialised to form your API? Or out of the shared code that generates the pre-defined API object you're returning? If your SQL is tied rigidly to the API to the extent that changing a query changes the API, what are you going to do when you want to restructure your database without breaking your API callers? Or when you want two versions of your API whilst you rewrite your clients or perform gradual upgrades?