I almost bought this book by mistake, a nagging little feeling about something in the table of contents made me triple-check before purchasing.
Not only is this book entirely devoted to web APIs, but its description and introduction are written from a perspective that doesn't quite realize that any other kind of API exists.

I am interested in API design myself, and I do realize that web APIs are a thing, but when I hear the term "API", my mind automatically leaps to things like DirectInput, XAudio2, GDI, WinSock, the Lua C API, and the like, which is a context in which I hear "API" far more often.

The challenges of writing good web APIs don't have a lot of overlap with that kind of thing, outside of the lowest fundamentals, so it would surely disappoint a non-web developer who is looking to improve his API design if they bought this book.

In summary: since the book is entirely devoted to web APIs, which are a very specialized subset of all APIs in general, I feel it would behoove the author to use the term "web" at least once somewhere in the book's description page...and preferably make the very specific nature of the subject matter explicit.

Hi,

I'm deeply sorry that the book's title and description almost misled you; this book is indeed about "Web" APIs.
After checking the book's web page content, I realized that it's definitely not explicit unless you spot words such as SOAP or REST or read the first chapter. The book's webpage has been modified in order to make the book's subject explicit. Thank you very much for your alerting.

Regarding Web APIs design vs "not web" APIs design, I think that API designers working on "things like DirectInput, XAudio2, GDI, WinSock, the Lua C API, and the like" (and any software's library, especially in the proprietary software space) should definitely look at what is happening in the web API space and especially public web APIs. Now that I have seen brilliant Web APIs that can be used so easily because of their design but also the overall experience some can provide (the famous "DX") I have become far more demanding and challenging with software in general. Many of the lessons I have learned on web API design could definitely be applied to API design because many of these lessons revolved around the "lowest fundamentals".

That's why even if my book is undoubtedly not about "not web" API design and some part may be specific to web APIs, I think that it still may be of interest for "not web" API designers. But of course it should only be seen as an "additional book to broaden perspective" as it is not solving "not web" API design problems specifically. It's always interesting to broaden perspective with "maybe not so closely related" material, I have learned quite interesting things about software and API design while reading "real world object design" books and articles for example.
BTW, the API design matters message in this forum points to an article about "not web" API design which is definitely interesting for any web/not web API designer. It comes full circle.

Thanks again for your alerting.

Arnaud