Adopt AEP-202: Fields #155
Conversation
|
Added a few high-level comments - will do a more thorough read of the PR once those are resolved. |
|
Added the proto file for |
|
Should we generalize this guidance to cover |
We should do that in a subsequent PR. I think they'll be a lot of conversation about that. |
| that are validated by the service, so conveying the format to the user ahead of | ||
| time is critical to their experience. | ||
|
|
||
| #### Why discourage primitive equality comparisons? |
There was a problem hiding this comment.
It seems like there should be actual guidance that this explains. I think the rationale makes sense, we just need the corresponding guidance.
There was a problem hiding this comment.
Yeah, this is too vague as-is. The biggest pieces of guidance I can think of are:
- Fields that follow a pattern must have that pattern specified as proto-validate
- Both the request + response fields must have the validation + and the validations must match (if applicable)
- Returning a value that does not match the validation must return an error message.
Any others you can think of?
There was a problem hiding this comment.
I meant specifically for "Why discourage primitive equality comparisons?"
Which guidance discourages primitive equality comparisons?
Co-authored-by: Richard Frankel <richard@frankel.tv>
Co-authored-by: Richard Frankel <richard@frankel.tv>
Co-authored-by: Richard Frankel <richard@frankel.tv>
Co-authored-by: Richard Frankel <richard@frankel.tv>
Co-authored-by: Richard Frankel <richard@frankel.tv>
Co-authored-by: Richard Frankel <richard@frankel.tv>
Co-authored-by: Richard Frankel <richard@frankel.tv>
Addresses #148
This adopts AEP-202: Fields
Note: this still uses the google.api.field_info proto type.