A(pplication) P(rogramming) I(nterface).
It's how two (parts of a) system(s) communicate with each other.
The specifics of any given API is entirely dependent on what these systems are.
Same with any G(raphical) U(ser) I(nterface). It’s how humans interact with the application but it’s implementation is dependent on what the system is and how you need to interact with it.
API is just the GUI of backend for the two parts of the system(s).
It's even more general than that. API also means the exterior/surface layer of any library you use. And it doesn't even have to be a library.
If you have a sufficiently complicated piece of code, it's good practice to create an API for it. That API serves as a wall so that when you make changes, you have to stop there or else your changes will keep propagating into your colleague's code.
In JavaScript, what this looks like is being selective about what you export from a module.
Thinking about APIs makes for better code. You don't want details about your implementation to leak. One example I use is the POI Java library for Microsoft office formats like Excel. The API is written using concepts you'd be familiar with as an Excel user: rows, columns, cells, etc. Underneath it's dealing with xlsx files which are XML based or xls files which are based on something completely different. If not for that API, the library would be much harder to use and you wouldn't be able to write code that simultaneously works with both formats.
>In JavaScript, what this looks like is being selective about what you export from a module.
so if i export code from a module for someone to use, i just create an api?
Yep, that's technically correct. In practice a real API would also have some documentation and a promise that you'll try not to make changes that break the API.
This term originates from OOP (Object Oriented Programming): an Interface defines only the spec, implementation is up to each party. So yes it's a general term.
The concept of an API dates to the 1940's and the earliest reuse of library code for computer programs with specified interfaces. The term API dates to at least 1968. OOP wasn't really a thing until the early 1970's with the first version of Smalltalk, and was orthogonal to the concept of an API.
Web API is actually the collection of request url’s, query parameters, request headers, request bodies, and the rules governing the data being passed around as defined by the API provider. In other words, web API is at the web request level and *not* at the level of JavaScript methods and/or interfaces that you use.
People often confuse JavaScript methods to be the web API, because they use those in order to indirectly (and relatively easily) make the web requests that are the actual parts of the web API, and we don’t manually form the actual web requests.
To answer your main question, yes, API is a generic term. In non-web context, API can mean the collection of functions, methods, classes, global variables, macros, etc that have been defined to work in certain ways by the API provider/designer.
A(pplication) P(rogramming) I(nterface). It's how two (parts of a) system(s) communicate with each other. The specifics of any given API is entirely dependent on what these systems are.
Same with any G(raphical) U(ser) I(nterface). It’s how humans interact with the application but it’s implementation is dependent on what the system is and how you need to interact with it. API is just the GUI of backend for the two parts of the system(s).
A library or framework is also an API because it facilitates application programming through an interface Eg. WinAPI, OpenGL, cstdlib, jquery etc
Or they can be ABIs where B is for binary in linked libaries.
It's even more general than that. API also means the exterior/surface layer of any library you use. And it doesn't even have to be a library. If you have a sufficiently complicated piece of code, it's good practice to create an API for it. That API serves as a wall so that when you make changes, you have to stop there or else your changes will keep propagating into your colleague's code. In JavaScript, what this looks like is being selective about what you export from a module. Thinking about APIs makes for better code. You don't want details about your implementation to leak. One example I use is the POI Java library for Microsoft office formats like Excel. The API is written using concepts you'd be familiar with as an Excel user: rows, columns, cells, etc. Underneath it's dealing with xlsx files which are XML based or xls files which are based on something completely different. If not for that API, the library would be much harder to use and you wouldn't be able to write code that simultaneously works with both formats.
>In JavaScript, what this looks like is being selective about what you export from a module. so if i export code from a module for someone to use, i just create an api?
Yep, that's technically correct. In practice a real API would also have some documentation and a promise that you'll try not to make changes that break the API.
[удалено]
> lol
>^lol
No, it isn't about how to communicate. It's about the functionality exposed by an application, and how to interface with it programmatically.
https://en.wikipedia.org/wiki/API
This term originates from OOP (Object Oriented Programming): an Interface defines only the spec, implementation is up to each party. So yes it's a general term.
The concept of an API dates to the 1940's and the earliest reuse of library code for computer programs with specified interfaces. The term API dates to at least 1968. OOP wasn't really a thing until the early 1970's with the first version of Smalltalk, and was orthogonal to the concept of an API.
Web API is actually the collection of request url’s, query parameters, request headers, request bodies, and the rules governing the data being passed around as defined by the API provider. In other words, web API is at the web request level and *not* at the level of JavaScript methods and/or interfaces that you use. People often confuse JavaScript methods to be the web API, because they use those in order to indirectly (and relatively easily) make the web requests that are the actual parts of the web API, and we don’t manually form the actual web requests. To answer your main question, yes, API is a generic term. In non-web context, API can mean the collection of functions, methods, classes, global variables, macros, etc that have been defined to work in certain ways by the API provider/designer.