* You have one chance to get the API right<p>* API’s can make or break the company<p>* Everyone is an API designer. If you program, you are an API designer.<p>* Good API: Easy to use, learn, hard to misuse, just powerful enough, easy to evolve, appropriate for the audience (API terminology)<p>* Process<p>- Gather requirements - Be Skeptical - Hear the un-said.<p>- Convert requirements to use-cases<p>- Start with a short spec - ideally 1 page<p>-- Don’t create a long spec first time around - it gets associated with the ego and then iterate<p>- bounce it off of the stakeholders<p>* Write to your API early and often. Basically, write tests early.
- These probably will live on to become examples on how to use the API
- Make sure these are exemplary as the examples will be used by consumers to base off their code.<p>* Maintain realistic expectations
- You won’t be able to please everyone
- Aim to displease everyone equally<p>* Expect to make mistakes
- API design is hard
- Expect the API to evolve<p>* Principles of good API design: 
- Should do one thing and do it well.
- Should be easy to explain.
- Should be easy to name<p>* Should be as small as possible but not smaller
- When in doubt, leave it out.
- It’s easier to add it later than to remove it.<p>* Implementation should not impact API<p>- details confuse users<p>- inhibit freedom to change an implementation<p>--- eg: catching SQL exceptions by the client<p>-- Do not let implementation detail leak into the API<p>--- Eg: implements serializable - all private fields are now public after serialization<p>* Minimize accessibility of fields<p>- Make classes, fields as private as possible<p>- public classes should not have any public fields, with the exception of constants<p>- Minimizes coupling<p>* Names matter<p>- Names should be self-explanatory<p>- Be consistent<p>- Be regular- strive for symmetry<p>--- If key and entry are two attributes, and addKey  and removeKey are methods on ‘key’ then there should be ‘addEntry’ and ‘removeEntry’<p>* Document religiously<p>- Document every class, interface, method, constructor, parameter and exception.<p>- Method documentation : contract tween method and it’s clients : pre-conditions, post-conditions, side-effects<p>- Parameters : indicate ownership(can I modifiy it ?), units (size of blocks in bytes), form (String : XML ? json)<p>* Document state space religiously<p>---- 37 minutes in the video ----
To be continued...