5
CORS is not a security feature. Only code running in browsers will care for CORS because browsers will use CORS.
Any regular application is free to call your API ignoring CORS.
Please repeat: CORS is not a security feature.
That said: why not. If you want it only called from your frontend, just do it. It won't keep others from calling you anyway though. it's ...
4
Requirements to remove fields from an API (regardless if it is a REST API, a classic library, or some other kind of component) can usually be resolved by removing those fields semantically, not syntactically. So the body of a message may still contain the field, but
the content of that field can be always left empty by the sender
and always be ignored by ...
3
Throw exceptions.
You are correct in that you should throw exceptions for exceptional things. But in this case it is exceptional for the API to throw a validation error, as you are checking for them on the client before sending.
You should only see this exception if the client has a bug that lets incorrect data through.
1
Is there a better approach to tackle this ? Any idea is greatly welcomed !
Depending on your use-case there may be better ways.
If you have 1 (web) frontend for your backend, then this separation through an API might make no sense in the first place. By introducing an indirection/abstraction, you'll just generate more work and make the whole thing less ...
1
I don't understand how I could create a stateless REST API that meets these requirements.
Stateless, in the context of REST, means something very specific:
each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
It's perfectly normal to have ...
Only top voted, non community-wiki answers of a minimum length are eligible
