Having a hard time explaining API to your boss?  Sure, you could send him or her to wikipedia, but even that looks kind of technical.  I came up with this analogy today and it seems pretty good:  The Fast Food Drive Thru.

Yes, that's right.  The drive thru window is your API and you communicate through it.  It doesn't matter what car the customer is driving.  All that matters is that they know how to communicate their order; something like "I'd like a cheeseburger, large fries and coke".  Then the response given back by the employee at the window, is the actual food (and sometimes change).  Documentation for the API?  That's the big menu that you pull up to before you order.   Actually, the synchronous API is the one where you both order *and* receive your food at the window.  Asynchronous would be if you ordered at the menu and by the time you got to the window your food was ready and you didn't have to wait.   A webservice, while I'm at it, is just a specific kind of API - the sending and receiving of data is done over the web.  Just like, you don't have to use the drive thru; you could park the car and go in and then order at the counter and get your food that way. 

If you need to explain SOAP, it's just part of the mechanism that hides the details of your ordering and receiving.  In Pennsylvania they have this great convenience store called Wawa, that also sells sandwiches, breakfasts, soups etc.  Instead of verbally communicating your order, you punch it in on a touchscreen and it appears on the monitor of the person making the food, and it gives you a receipt.  You pay at the register, they stamp your receipt as paid,  and then when they call your number, you give the receipt to the guy making the sandwich and he gives you the food.  SOAP, is just a method of encapsulating your request.  You don't really need to know the technical details of what happens to get your order from your finger tips to the sandwich guy's monitor.