Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
| en:general:accessibility_desk_mobile_apps [2023/03/10 15:22] – [Documentations for mobile applications] thinder | en:general:accessibility_desk_mobile_apps [2023/03/10 15:24] – [API naming] thinder | ||
|---|---|---|---|
| Line 28: | Line 28: | ||
| </ | </ | ||
| + | |||
| + | ====API and schema design examples==== | ||
| + | - use_underscores | ||
| + | - useCamelCase | ||
| + | - use-kebab-case | ||
| + | |||
| + | ==== Examples of IDs and similar entities ==== | ||
| + | - use.dot.separators (often with reverse DNS prefixes) | ||
| + | - use/ | ||
| + | - use-hyphen-separators (often with GUIDs and the like) | ||
| + | |||
| + | ==== Abbreviations ==== | ||
| + | Another common challenge is the use of shortcuts. While a user interacting with your API may recognize your abbreviations from context, a screen reader may not be able to do so, especially if your abbreviation is not common. | ||
| + | ^Abbreviated (unfavorable) ^Not abbreviated (correct) ^ | ||
| + | | pvtKey | privateKey | | ||
| + | |||
| + | ==== Additional services ==== | ||
| + | An added benefit is that code generators can more easily produce idiomatic terms that conform to case-sensitive conventions in the target language/ | ||
| + | ^JSON ^Dotnet ^Dotnet with additional suffix ^ | ||
| + | | dataContentType | DataContentType | DataContentTypeEntity | | ||
| + | |||
| ===== Check list ===== | ===== Check list ===== | ||