Confirmed users
657
edits
WebAPI/DesignGuidelines: Difference between revisions
→Considerations
No edit summary |
|||
| Line 5: | Line 5: | ||
==Considerations== | ==Considerations== | ||
* start with a use case which you're trying to solve, and try to avoid scope creep to fix unrelated problems | |||
* design the solution at the right level, for example if the use case is to address a specific UX requirement, think of how you can design the API to keep it intact in the face of future changes to the UX requirements. Sometimes this means designing a lower level API with the expectation of some client code being written on top of it to satisfy the existing UX requirements. | |||
* user privacy and data/hardware security | * user privacy and data/hardware security | ||
* fingerprinting | * fingerprinting | ||
| Line 11: | Line 13: | ||
* work with the strengths of the web and JavaScript (e.g. IndexedDB works directly with JS objects and doesn't require serialization to SQL primitives) | * work with the strengths of the web and JavaScript (e.g. IndexedDB works directly with JS objects and doesn't require serialization to SQL primitives) | ||
* use new features instead of old ones (e.g. Promises instead of DOMRequests, WebIDL, ...) | * use new features instead of old ones (e.g. Promises instead of DOMRequests, WebIDL, ...) | ||
* the design of APIs only exposed to privileged or certified apps is less important than those that will be exposed to the web at large | * the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large | ||
** standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors | ** standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors | ||
* bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers | * bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers | ||