4 ms·
Implementing REST APIs with Embedded Privacy
- hack37 13y agoIn software development we call it abstraction. Privacy is for real people.
- andyfang 13y agoYou 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.
- nwenzel 13y agoIn 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.
- thibauts 13y agoWhy 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.
- andyfang 13y agoWe 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.
- thibauts 13y agoYou'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.
- SoCool 13y agoI 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.