Building APIs That Rock

elmo can't code

need for modules to be configurable w/o going through UI to set options/settings; eg Views and Views UI
API's are the tool that let modules use other modules; code is user with no hands analogy

messaging module - abstracts sms, mailing, jabber, etc means of sending messages

API's hide complexity and get everyone on the same page

steps to creationg API; Voting API for example; basically the same as buidling a class structure
	find the nouns - what are the pieces of data; eg vote
	find the verbs - eg set and get; becomes the functions
	add flexibility - eg add vote, change vote, delete vote; subdividing functions and adding parameters to data points
	
	
important to consider naming conventions and stick with them	
important::don't use numerics as constant types, use string keys instead to prevent clashes; unless you know the enumerated list won't change

calling hooks from other modules: use module_invoke_all() function
drupal_alter() - call any of the ....alter methods registered by other modules; data set is passed in by reference; "it's like passing around the doobie of data, everyone gets a chance, but you don't have to"

seven deadly api building sins
	lone ranger - reinvents wheel, ignores conventions and related API's; common from new users or obsessives
	invisible assumptions - eg assuming global $user or checking arg(0)
	helping them to death - doing too much; commone when API grows from very specific use case
	leaky abstractioin - abstraction doesn't quite work, requires under-the-hood knowledge; common in tricky problem domains; simplify or get out of the way
	fake flexibility - usggestion: build 3 test implementations for different use cases
	mission creep - worse than feature creep
	dependency soup - inverse of mission creep; module require too many dependencies; make dependencies optional, degrade gracefully