Resources for software developers and product owners.
For programmers, APIs has been part of their life since the early beginning of programming.
For businesses, APIs are increasingly becoming valueable assets and that should be managed accordingly.
"APIs can be among a company's greatest assets" [J. Bloch, Google, 2007]
Why APIs Are Agents of Change for Digitalization, CIO Insight, 2016-04-19
Why APIs Are Worth The Time And Attention Of IT Professionals, InformationWeek, 2016-09-09
"An API differs from an application binary interface (ABI) in that an API is source code-based while an ABI is a binary interface. For instance POSIX provides APIs, while the Linux Standard Base provides an ABI.[13][14]" [wikipedia, on API]
API vs SPI
From mussabsharif.blogspot.ro/2011/08/api-vs-spi.html (R: 2016-10-10)
What is the difference between API and SPI ? This is what we are going to explore in this blog post :-)
API stands for Application Programing Interface, where API is a mean for accessing a service / function provided by some kind of software or a platform.
SPI stands for Service Provider Interface, where SPI is way to inject, extend or alter the behavior for software or a platform.
Normally developers get mixed with the above types of interfaces and provide a cocktail of both with out understanding who are the intended actors for both and what are there use cases.
API is normally target for clients to access a service and its has the following properties:
- API is a programmatic way of accessing a service to achieve a certain behavior or output
- From API evolution point of view, addition is no problem at all for clients
- But API's once utilized by clients it can not (and should not) be altered / deleted unless there are an appropriate communications, since its a complete degradation of the client expectation
SPI on the other part are targeted for providers and has the following properties:
- SPI is a way to extend / alter the behavior of a software or a platform (programable vs. programmatic)
- SPI evolution is different that SPI evolution, in SPI removal is not an issue
- Addition of SPI interfaces will cause problems and may break existing implementations
Normally splitting the two type of the API's is best practice, but some times a blur line appear about what should be an SPI and what should by an API.
This comes from the perception that API is something to call and SPI is something to implement, also to add, if you asked two people about both you may get two different answers about what they are :-)
The bottom line, think about both type of interfaces the next time you design your system or solution, since you don't want to make your end users frustrated or confused !
I would recommend reading the book Practical API Design Practical API Design: Confessions of a Java Framework Architect to get more on the subject.
google.com/search?q=Practical+API+Design%3A+Confessions+of+a+Java+Framework+Architect
Also I would recommend to view the following videos: How To Design A Good API and Why it Matters and the Paradoxes of API Design.
From wiki.netbeans.org/DevFaqApiSpi (R:2016-10-10)
DevFaqApiSpi
What is an SPI? How is it different from an API?
API is a general term - an acronym for Application Programming Interface - it means something (in Java, usually some Java classes) a piece of software exposes, which allows other software to communicate with it.
SPI stands for Service Provider Interface. It is a subset of all things that can be API specific to situations where a library is providing classes which are called by the application (or API library), and which typically change the things the application is able to do.
The classic example is JavaMail. Its API has two sides:
- The API side — which you call if you are writing a mail client or want to read a mailbox
- The SPI side if you are providing a wire-protocol handler to allow JavaMail to talk to a new kind of server, such as a news or IMAP server
Users of the API rarely need to see or talk to the SPI classes, and vice-versa.
In NetBeans, when you see the term SPI, it is usually talking about classes that a module can inject at runtime which allow NetBeans to do new things. For example, there is a general SPI for implementing version control systems. Different modules provide implementations of that SPI for CVS, Subversion, Mercurial and other revision control systems. However, the code that deals with files (the API side) does not need to care if there is a version control system, or what it is.