I think, the approach is right but the implementation can be more elegant. Keeping scalability and readability in mind, I would use more declarative/DSL syntax to fine control your resources. Django uses the metaclass to achieve something similar.

In software development we call it abstraction. Privacy is for real people.

You can also say privacy is about protecting people's information, which is what abstraction allows us to do. It's also a matter of where to make the permissions decisions, at the view level or at the API resource level? At DoorDash, we've found that making that choice at the API resource level was the right decision.

In software there are usually multiple places to accomplish the same thing. I usually ask, "where do I put the work?" I'm usually thinking of the database vs. the framework on the server vs. the client.

The post is a great explanation of the choices and why the API resource was the way to go. Inspired us to take a look at how we put our API together.

Why not use one resource and return different fields depending on the type of the requesting user ? I have the same problem to solve right now and not sure yet which way to go.

We thought about this approach. This would mean that we'd have to have fine-grain permissions logic every time we used that resource. An analogy to this is like having to sanitize literal strings for every user input from a web form; if you forget to sanitize (or in the API case forget to filter the fields) at any point, you have a security bug in your code.

You're still doing filtering. The difference I see is your database request code is duplicated. Conceptually the condition is moved but it is bound to exist somewhere. This is IMO a semantics question. Thanks for your input anyway, you gave me a new perspective to wonder.