RFC: Ignore extra columns
See original GitHub issueSummary
Allow additional fields in REST inbound payloads.
Motivation
.NET developers serialize and deserialize JSON payloads into classes. Before this enhancement, DAB would require two different Request and Response payloads. The reason for this is that REST payloads to DAB could not include key and read-only fields. To solve this, .NET developers either 1) maintain two sets of POCO/DTO models - which is far from idea - or 2) manipulate the outbound payload dynamically - which is even further from ideal.
Old behavior
This demonstrates DAB behavior we want to change.
SQL Schema:
CREATE TABLE Customer
(
Id INT PRIMARY KEY IDENTITY(1, 1),
First VARCHAR(50),
Last VARCHAR(50),
Name AS CONCAT(First, ' ', 'Last)
)
POST (insert) {server}/API/customer
Request body:
{
"Id": 1,
"First": "Jerry",
"Last": "Nixon",
}
Response body:
{
"Id": 1,
"First": "Jerry",
"Last": "Nixon",
"Name": "Jerry Nixon",
}
PUT (update) {server}/API/customer/Id/1
Request body:
{
"First": "Jerry",
"Last": "Smith"
}
Note: If either
Id
orName
were included in the Request body, DAB would return an error.
Response body:
{
"Id": 1,
"First": "Jerry",
"Last": "Smith",
"Name": "Jerry Smith",
}
New behavior
This demonstrates DAB behavior we want as a result of this enhancement.
SQL Schema:
CREATE TABLE Customer
(
Id INT PRIMARY KEY IDENTITY(1, 1),
First VARCHAR(50),
Last VARCHAR(50),
Name AS CONCAT(First, ' ', 'Last)
)
POST (insert) {server}/API/customer
Request body:
{
"Id": 1,
"First": "Jerry",
"Last": "Nixon",
}
Response body:
{
"Id": 1,
"First": "Jerry",
"Last": "Nixon",
"Name": "Jerry Nixon",
}
PUT (update) {server}/API/customer/Id/1
Request body:
{
"Id": 1,
"First": "Jerry",
"Last": "Smith",
"Name": "Jerry Smith",
}
Note: Both
Id
andName
are included in the Request body. As they are primary key and read-only fields, DAB ignores them. No error is returned (please see configuration setting necessary for this behavior below).
Response body:
{
"Id": 1,
"First": "Jerry",
"Last": "Smith",
"Name": "Jerry Smith",
}
Functional Specifications
This enhancement only applies to the REST side of DAB.
The basics
- This behavior is part of the .9 theme to remove adoption friction for enterprise developers.
- DAB behavior does not change from current behavior without configuration flag (see below).
Desired behavior
- Any JSON property that does not map to a database field is ignored. (PUT, POST, DELETE)
- Any JSON property mapping to a read-only primary key is ignored.
- Any JSON property referring to a read-only, computed column is ignored.
Ignoring read-only fields requires knowledge of the database object metadata.
Configuration change
Introduce request-body-strict
to the dab-config.json file.
{
"runtime": {
"rest": {
"enabled": true,
"path": "/api",
"request-body-strict": false 👈
},
}
}
Value | Meaning |
---|---|
true | Extra fields are not allowed, results in error |
false | Extra fields are allowed, ignored |
Note: when the value is not present in the config file, it is the same as being present as
true
; that is, strict mode is on.
Normal behavior does not change
- If a key is read-write and I include it in the request payload, is the DB be updated during a PUT? Yes.
- If a key is read-write and I include it in the request payload, is the DB be updated during a POST? Yes.
Enhancement Q&A (when configured to not-strict
)
- Can properties mapping to read-only keys (db-generated) be included in the Insert payloads? Yes.
- Can properties mapping to read-only keys (db-generated) be included in the Update payloads? Yes.
- What happens when properties mapping to read-only keys are included? They are ignored.
- Can properties mapping to read-only computed fields be included in the Insert payloads? Yes.
- Can properties mapping to read-only computed fields be included in the Update payloads? Yes.
- What happens when properties mapping to read-only computed fields are included? They are ignored.
- Can properties not mapping to any database field be included in the Insert payloads? Yes.
- Can properties not mapping to any database field be included in the Update payloads? Yes.
- What happens when properties not mapping to any database field are included? They are ignored.
- Does property data type change (e.g.: scalar, array, object) this behavior? No. Regular REST limitations apply.
- How many extra fields are supported? Is there a max? No. Regular REST limitations apply.
- Are ignored properties forwarded to the response payload? Never. They are ignored.
- Are ignored properties populated in the GET response payload? Never. They are ignored.
- Are ignored properties compared to the URL key value? Never. They are ignored.
- Can I bypass the need for metadata by indicating which fields are read-only somehow? No.
OpenAPI Updated
OpenAPI will need to be updated to reflect this change in payload requirements.
References
Issue Analytics
- State:
- Created 2 months ago
- Comments:13 (10 by maintainers)
Specifically, the package
commandlineparser
https://github.com/commandlineparser/commandlineUnderstood. While this is true, should we validate
strict:false
is incompatible with “mysql” indata-source.database-type
?That’s right. Yes.
Yep, I updated the original comment to correctly be
post
andput
respectively. Good catch.