Web Services - that's standard defined by W3C, so they can be accessed semi-automatically or automatically (WSDL / UDDI). The whole thing is based on XML, so anyone can call it. And every aspect of the service is very well defined. There's parameters description standard, parameter passing standard, response standard, discovery standard, etc. etc. You could probably write 2000 pages book that'd describe the standard. There are even some "additional" standards for doing "standard" things, like authentication.
Despite the fact that automatic invoking and discovery is barely working because clients are rather poor, and you have no real guarantee that any service can be called from any client.
Web API is typically done as HTTP/REST, nothing is defined, output can be for eg. JSON/XML, input can be XML/JSON/or plain data. There are no standards for anything => no automatic calling and discovery. You can provide some description in text file or PDF, you can return the data in Windows-1250 instead of unicode, etc. For describing the standard it'd be 2 pages brochure with some simple info and you'll define everything else.
Web is switching towards Web API / REST. Web Services are really no better than Web API. Very complicated to develop and they eat much more resources (bandwidth and RAM)... and because of all data conversions (REQUEST->XML->DATA->RESPONSE->XML->VALIDATION->CONVERSION->DATA) are very slow.
Eg. In WebAPI you can pack the data, send it compressed and un-compress+un-pack on the client. In SOAP you could only compress HTML request.
I think it rather falls along the lines of "All SDKs are APIs but not all APIs are SDKs".
An SDK seems to be a complete set of APIs that allow you to perform most any action you would need to for creating applications. In addition an SDK may include other tools for developing for the platform/item that it is for.
An API on the other hand is just a series of related methods that may be good for a specific purpose.
As an example, the JDK (Java Development Kit) contains the API as well as the compilers, runtimes, and other miscellaneous tools. The Java API is simply all the libraries that make up the core language that you can work with out of the box.
Best Answer
I'll talk about Akka/Scala, because I'm not familiar with Gpars nor with Akka/Java.
In Scala 2.10, which includes the relevant part of Akka in the standard distribution, a
Futureis essentially a read-only reference to a yet-to-be-computed value. APromiseis a pretty much the same except that you can write to it as well. In other words, you can read from bothFutures andPromises, but you can only write toPromises. You can get theFutureassociated with aPromiseby calling thefuturemethod on it, but conversion in the other direction is not possible (because it would be nonsensical).