In the API Pages, at the field level, we currently find that almost none of the available properties actually work, even though the compiler and the CodeCops do not warn you that they will not work...

We speak, for example, of the NotBlank property, which only protects us in the writings of the value `null` but not of "".

Other properties such as MinValue, MaxValue, Numeric, ValuesAllowed or DecimalPlaces do nothing directly, which means having to control all this type of thing by code.

Also, when creating a custom table as an API inbox, it is not possible to use the standard SystemId field as Primary Key, so we have to define a custom field of type GUID or BigInteger just to be able to define its PK, despite that we then use ODataKeyFields = SystemId following the recommendations of the existing documentation.

Finally, we find that it is not possible to hide fields such as PrimaryKey or SurrogateKey from read or write actions using the Visible property (which does nothing in the API Pages either).

We need to be able to indicate in some way in each field, at the Table level (or at the Page level at least), if every field should be included in responses or allowed in requests for each of the GET, POST and PUT operations separately... it's totally something common in other technologies.