☒ Can you explain your requirements a bit more? I understand that you're wanting to prevent anything from calling your application except for your application specifically (whether front end or back end). For your particular example with the /users.json, is there any checks in place on that action to only return authorized users, rate limiting, pagination, etc? Is your front end completely separated from the back end?
Unauthorized users should return 401. You should pass a cookie with the session or a JWT to validate a user's access to the resource.
☒ If you find yourself in a situation where there are already a bunch of callbacks in the model and you're wanting to clean things up a bit, there are a few approaches you can take. First, start to separate and isolate things. You can do this with namespaced concerns. This will help you get an overview at a glance what you'll be dealing with. Otherwise, code from the model will start to blend in and it will be confusing. Once things are separated, the decisions can be made to leave it the way it is or to start removing the callbacks. Having appropriate test can help expose any breaks in your refactors so I'd say that will be an important part; especially for a large model. Try to identify where the parts are that could ultimately trigger the callback as you'll likely need to touch those areas of code. Overall, I think that the main ones that I would focus on would be the ones that involve other models. Those tend to be the most brittle and the most trouble makers. A callback which only affects the model record itself is usually okay and could be argued that it is "good enough" to be left alone.
