TPAC/2011/API Design Approaches and the Rationales for Them
API Design Approaches and the Rationales for Them
- Led by: Bryan Sullivan/proposed by Ileana Leuca
What API design approaches are browser vendors seeking to promote, and what are the rationales for the choices? How can W3C help the wider Web community (including SDOs that want to Web-enable their standards-based service enablers, or extend the Web platform with new capabilities) follow a successful path to convergence with W3C? For example what are the rationales behind the following API design approaches?
- declarative (via markup language features, e.g. HTML5's <video> tag)
- XHR/REST (using HTTP scheme URLs such as in conventional RESTful Web APIs, and non-HTTP scheme URLs handled by the browser or some local system-registered URL handler)
Results from the Session
The key points captured from the session:
- Data Minimization (draft: http://www.w3.org/2001/tag/doc/APIMinimization.html) for privacy protection is one of the key considerations in API design.
- Design guidelines are valuable parts of the process. They should be living, but mostly non-normative. We need to be able to evolve design approaches and practices.
- API design extensibility is a key consideration.
- APIs should be usable. We need to learn from why developers need libraries, e.g. by reaching out to the library developers for their input.
- APIs that deal with I/O or user input should be async, and result in non-blocking user experience. But sync APIs may be acceptable where the performance impact of the API is minimal.