The abbreviation "SPI" comes up a lot of in the WebKit codebase, as well as WebKit maintainer discussions.
The term seems to have the following meanings associated to it:
Low(er)-level API in use by WebKit logic
Underlying implementation to be supplied by the platforms that WebKit compiles to.
So this has quite a bit of similarity with the term PAL (Platform Abstraction Layer), in particular it feels like it means "an API belonging to PAL".
However, googling "SPI" only gives Serial Peripheral Interface, which is probably not what the abbreviation is referring to here. Does it just mean something like "system programming interface"?
SPI stands for service provider interface and it's essentially a plugin-based architecture, where a platform can define some abstract functionalities as interfaces. The various plugins can then define implementations for these interfaces to provide this functionality.
The name for this pattern was widely used in Java, but it's now being used in other languages/frameworks as well.
This post contains a more detailed description of a Webkit SPI for accessibility.
See also: https://en.wikipedia.org/wiki/Service_provider_interface
Related
So I was going through the Wikipedia page on API, in the first paragraph it is stated that
A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation.
While I understand the 'specification' part of the definition, I didn't get what 'implementation' here means.
Taking Python as an example, whenever I'm writing a program in it I understand that I'm using it's API specification (or API), but what does 'implementation' mean here? Is it the source code of the Python that was used to build this API or object code or something else. And if it really is source code or object code, then it feels counter-intuitive to call them as API to me — so far in my experience I used to see only specification as API. So, if you could kindly help me to resolve this long lasting query, I'll be highly grateful. Thanks.
Sometimes, people use the term 'API' to refer to a library that implements a particular API. This strikes me as a mis-use of the term, but it might be what motivated the Wikipedia article to say "The term API may refer ... to the implementation". There's some discussion of that on the article's 'Talk' page.
"The term API may refer ... to the implementation" is just a suboptimal wording.
Just take the later in that wikipedia article "The calls that make up the API are also known as subroutines, methods, requests, or endpoints. An API specification defines these calls, meaning that it explains how to use or implement them." which points to what I would phrase "the way you call functions, methods, etc. in a programming language are part of the 'API' of that programming language".
The thing that I stipulate the author of "... to the implementation" meant. You could contact him/her directly to clarify that.
It is complicated because API, protocol, ABI have quite some overlap. "API" is in practice the catch-all for saying "something interacts in a controlled way with a system. May it be an Interpreter, an HTTP-service, a dynamic library (because it is ... "an interface (of some kind) to a system" (of some kind).
That said: "implementation" is IMHO a misleading wording. The API is the interface.
If I do a GET request to nginx or apache ... the "API" would be HTTP and the implementation however nginx and apache do to reply to the HTTP request.
If I do a function call to a Python function the API is the function signature; if the backend (what I would call the "implementation" is CPython or PyPy is not the API but the implementation.
The pointers to the talk page for that wikipedia article are worth a lot!
API and implementations with analogy
I like to think of APIs and implementations with a help of an analogy with some real-world devices, like a car for example. Each car has a steering system, which helps you steer the car (obviously). But in order to use this system, you don't have to know how it works and how it's implemented, so you interface with it via a steering wheel. This also has the benefit of each car manufacturing company having a relative freedom of how they can implement the steering system (because at the end of the day all the driver is worried about is the steering wheel). So in this example the steering wheel would be your API/interface, the steering system is the implementation and the driver is some client application.
APIs and implementations in code
This works similarly in code. When developing a software system or a library, you always choose which components (classes/methods/variables) are exposed to the client applications (the ones which use your system/library), and which ones stay hidden from them and become an implementation detail. The first is the API while the latter is the implementation. Imagine you develop a library of collection classes and utilities, and as part of your API you expose a sort(collection) function, which, as the name states, sorts a collection. Client applications will call this API without caring how it's implemented, so later you can change the underlying sorting algorithm without breaking any clients (they probably won't even know something changed, they are just calling the function same as before). In other words, your implementation can change without any changes to the API.
API specifications
Now, where the wording can get confusing is when we add API specifications into the mix. API specifications are often human-readable documents which describe said API (what classes/methods should be there and how they should behave). Such specifications are not code, they are just text-based documents aimed to guide developers to provide an implementation for this API. When a library implements such API specification, it will contain the actual API (code components which correspond to the specification and are exposed to the clients) and implementation (code components hidden from clients which do the actual work and are called by the API). Now, where confusion lies is that the whole library (including both API and implementation) can be called an implementation of the API specification (because this is actual code implementing what is written in a text document, even though this code contains both API and implementation). I think this is what is meant in the Wiki:
The term API may refer either to the specification or to the implementation.
meaning that when you hear the term API it can refer to either a formal text-based document describing said API or to the actual code components which form the API of some software implementation.
Word on Java interfaces: Java interfaces are basically code components which only have an API, meaning they have no implementation and are meant to be implemented by other classes. This allows developers to have API specifications in code so to speak, where they provide a package which contains only interfaces, and other vendors can use those when developing their implementations. This lets you enforce the specification more reliably, because now instead of simply relying on a document, implementation developers will add those interfaces as code dependencies and rely on the compiler to check whether they implemented every method correctly (of course they still need to worry about the intended behaviour themselves). That said, this only adds to the confusion, because now actual code can also be called an API specification.
The Asynchronous Messaging Protocol is a simple protocol in python-twisted. I have a fairly complete app (python, twisted, kivy) using it. The client-server architecture implements a view-controller sort of relationship, with allmost all business logic server-side and the UI interface code simply reflecting change in state of models (sent by server) and sending the appropriate AMP messages.
Here is a list of implementations of the AMP protocol in other languages, but some seen unfinished, and most don't seem to be actually being used for anything serious.
The use-case I'm looking at is a fully Python app which currently works on Windows, Linux, and Android (possibly iOS if I ever get round to building that). And possibly, in the future, replacing the View/UI bit with 'native' language (Java/Swift on Android, for instance) while keeping the business bits in python and twisted.
So I have two main questions:-
Is it accurate to say that AMP is only really used within python-twisted and those programs that use it?
Are there other, more generally useful network protocols which are both implemented and fairly easy to use in twisted as well as being non-specific (e.g. jabber is really only for chat)? Preferably which don't require a server like WAMP/autobahn do (if I understand correctly) so it can be self-contained within any device which can run python.
This isn't entirely accurate. Twisted just happens to use it the most. Other languages make use of AMP, it's just that AMP hasn't become very popular given popularity of other more robust options like AMQP (ZeroMQ, RabbitMQ, WebsphereMQ, etc).
AMP is about as simple as it can get. Also, it's unlikely you will find a solution without a server.
AMP is not locked to Twisted or Python. There are other implementations in other languages but like you said some are not used in a "serious" manner and often go unmaintained. Don't let that scare you off because the protocol is so simple, there often isn't much to do after it's been implemented. You will be happy to know that the actual protocol hasn't changed much and isn't very difficult to implement in any language if you follow the design. If you want something more generic, cross platform, and ensured compatibility, then consider HTTP requests.
could you please explain the difference between interface and API?
I was looking for this information here and using google but I only find a special information for Oracle.
What I'm looking for is the general difference.
Much appreciated!
Update:
thank you all for the answers. My question was kept deliberately general because I
1) do not have the detailed information about the used programming languages (question based on a short information about one vendor's implementation in my project);
2) I wanted to understand the general high-level difference between the both terms.
Without further context, your question is a bit broad; but lets try; by looking up the definition of API on wikipedia:
In computer programming, an application programming interface (API) is a set of subroutine definitions, protocols, and tools for building software and applications.
Then: API stands for application programming interface; indicating that well, an API contains all elements (plural!) required to create an application which wants to interact with the component behind that API.
Whereas an interface in its stricter sense typically denotes a "single specific entity"; like the List interface in java describes an ordered collection (without providing details about specific implementation).
But of course, there are certain commonalities - both terms are about the description of the "boundary" of a "system". Long story short: there is simply no sharp, precise separation between those two concepts. Thus, when using those words within a group of people, you might want to first "step back" and discuss terminology - to ensure that all people involved have the same understanding of such terms. Or as DDD puts it: you want to create a Ubiquitous Language in which such terms have a clear, well defined meaning.
Finally: it is also worth mentioning that the term interface has different meanings when using different programming languages. In Java, an interface is really a concept embodied within the language core; where as in C++, an "interface" would probably be seen as the content of a single header file; leading to subtle but important "flavors" of "interface" for those two languages.
Edit:
Both, interface and API should not expose (too much?!) of the internals to the outside world.
Generally speaking, an API outlines a "component" (a complete "application" for example); whereas an interface might outline a "smaller" entity".
For your other refinement, about one company providing the API, and another the interface - I cant say anything. Because; as others have explained too: the definitions for those terms are really to unclear/fuzzy. We would need to know much more about the application and its requirements to even comment on your statement here.
The question "what is the difference between X and Y" is only meaningful when X and Y have single meanings and strict definitions. But "interface" and "API" do not have either single meanings nor strict definitions, so one cannot tell what is the difference between them.
For the most part, there is no difference, but there exist certain contexts where one would be suitable to use, while the other would be less suitable, or even unsuitable.
So, for example, a class implements an interface, never an API. On the other hand, an entire software system is more likely to be said to expose APIs rather than interfaces, though to say interfaces in this case would not be wrong either.
I wish there was some easy distinction, like "interfaces are small-scale, APIs are large-scale", or "interfaces are more specific, APIs are more nebulous", but there is no such distinction.
Suppose I have written a library in a programming language (e.g. Java) to interact with an external component (e.g. a database).
I would now like the community to provide implementations in other languages.
How can I enable and encourage, other developers to provide implementations that are identical in functionality to mine.
Some examples may be:
Provide a written specification of behaviour
Provide a reference implementation
Provide a testing framework so they can validate their implementation (can this be done across multiple languages?)
What other options are available?
Common approach of all that you are after for, can be the abstraction level of Coding conventions. Since they are set of guidelines for a programming languages that recommend programming style, practices and methods for each aspect of a piece program written. These conventions usually cover file organization,indentation, comments, declarations,statements, white space, naming conventions, programming practices,programming principles, programming rules of thumb, architectural best practices, etc.
About
enable and encourage, other developers to provide implementations that are identical in functionality to mine.
you can use Interfaces (protocols). Even if they are used to define an abstract type that contains no data or code, they also define behaviors as method signatures.
Your examples are good. But in addition to
Provide a testing framework so they can validate their implementation
you can introduce the main ideas of the Test-driven development:
Establishing the goals of different stakeholders required for a vision to be implemented
Drawing out features which will achieve those goals using feature injection
The goal of developer TDD is to specify a detailed, executable design for your solution
read more
Can anyone think of the shortest possible definition for API, especially for someone who doesn't know programming? I'm using it in an essay and would like to footnote the definition for readers that might not understand the meaning or context of an app programming interface without tripping myself and the flow of the work.
From the wikipedia disambiguation page:
API, originally Advanced Programming Interface but now more commonly known by its near-synonym, Application programming interface, is any defined inter-program interface.
"any defined inter-program interface" is nice, but maybe a little broad for your purposes.
It's a lot of things (see wikipedia). But I usually think of it as the collection of tools and documentation that allow a user to interact with an external library or base of information.
Howstuffworks has a good definition:
An application-programming interface (API) is a set of programming instructions and standards for accessing a Web-based software application or Web tool.
I don't think API implies that the application must be web-based, but I otherwise like this definition.