Chaching can be done in many different ways for REST before going to catching requests server side. Look at ETag, expiry time, or others. Let the client do some work as well.
404 is used as well instead od 403 to properly protect resources. Why would a use know that a resource exists if they don't have access to it? It's implicit leakage of information or better yet meta-data as in "resource exists under given criteria like under given ID". And one could argue it breaks no REST rules as server cannot find any resource for given criteria that relates to that user.
Very good points, for example when it comes to auth you don't want to leak information about what kind of user data exists or doesn't with a 404. That enables to scan what data is there or not as a consumer of the API. Different status codes may be given to the same use cases depending on privacy or auth.
Good catch!
I agree to the extent that you are leaking metadata but the codes are for context. As a developer hitting your API I need a 403 or 401 to understand whether I have hit a rate-throttle or my token has expired and I need to reauthenticate.
And as a developer of API you use I don't want to give you that info so you get 404. Hehe. I understand your point but just a perspective on why you won't get it sometimes
Couple of things to add hope you don't mind:
Chaching can be done in many different ways for REST before going to catching requests server side. Look at ETag, expiry time, or others. Let the client do some work as well.
404 is used as well instead od 403 to properly protect resources. Why would a use know that a resource exists if they don't have access to it? It's implicit leakage of information or better yet meta-data as in "resource exists under given criteria like under given ID". And one could argue it breaks no REST rules as server cannot find any resource for given criteria that relates to that user.
Very good points, for example when it comes to auth you don't want to leak information about what kind of user data exists or doesn't with a 404. That enables to scan what data is there or not as a consumer of the API. Different status codes may be given to the same use cases depending on privacy or auth.
Good catch!
I agree to the extent that you are leaking metadata but the codes are for context. As a developer hitting your API I need a 403 or 401 to understand whether I have hit a rate-throttle or my token has expired and I need to reauthenticate.
And as a developer of API you use I don't want to give you that info so you get 404. Hehe. I understand your point but just a perspective on why you won't get it sometimes
And I'll just use a competitors company and their API because it's easier to code against
:)