[BUG] Missing validation on create /settings endpoint

[enrichman]

Describe the bug
It seems possible to create a completely empty setting (with blank name, blank category and empty value) in the POST /settings endpoint:

curl -X 'POST' \
  'http://localhost:1865/settings/' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "name": "",
  "value": {},
  "category": ""
}'

result:

{
  "setting": {
    "name": "",
    "value": {},
    "category": "",
    "setting_id": "aefed2ee-94ba-4975-9fd2-d37acd68794a",
    "updated_at": 1711723874
  }
}

Expected behavior
Maybe it's the expected behavior but I'm not sure if at least the name should be verified, or all the three fields.

[pieroit]

Having a basic validation could be useful
Do you want to make a PR?
The error messages should follow this format

Thanks and welcome ;)

[enrichman]

Thanks @pieroit for confirming that this is probably not expected. I'm not sure how this settings should be used. Is the name mandatory? What about category or the value?

IMO at least the name and the value should not be empty, but I don't know if also the category should be mandatory.

[pieroit]

Thanks @pieroit for confirming that this is probably not expected. I'm not sure how this settings should be used. Is the name mandatory? What about category or the value?

They should be used freestyle, so we can impose a minimal validation without restricting freedom (as a framework sould do).
In the future we may add the possibility to add custom validators via hook, but too soon for that.

IMO at least the name and the value should not be empty, but I don't know if also the category should be mandatory.

let's make all of them non null/empty
Assigned ;)

I may add the tests for this if you don't feel like it, because they are long due (my bad).
BTW they should go here