254
edits
WebAPI/DesignGuidelines: Difference between revisions
Jump to navigation
Jump to search
→Design considerations: Secure origins are apparently called authenticated origins now
(Note standardizing attack mitigations, highlighting in other specs to avoid monkey patching, and considering exposure to secure origins only (courtesy hsivonen)) |
(→Design considerations: Secure origins are apparently called authenticated origins now) |
||
| Line 76: | Line 76: | ||
* 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 but if this route is chosen, future standardization efforts will be hampered. | * 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 but if this route is chosen, future standardization efforts will be hampered. | ||
* 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. | ||
* sometimes it makes sense to limit API exposure to | * sometimes it makes sense to limit API exposure to authenticated origins (https:) only. | ||
* 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. | ||
* web APIs are "forever" so be very careful with what you expose to the web! maintain web compatibility! | * web APIs are "forever" so be very careful with what you expose to the web! maintain web compatibility! | ||