API alternative?

[Owen Densmore]

From twitter: Anyone have a better word/phrase for API -- Application Programming Interface?  Nick, this should be great for the Village Pragmatist.

Jeremy Ashkenas @jashkenas4h

Wanted: A better word for “API”. When talking about the interface that code exposes to the reader/user/programmer, API works, but is jargony

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[glen ep ropella]

Owen Densmore wrote at 05/01/2013 08:45 PM:
>>From twitter: Anyone have a better word/phrase for API -- Application
> Programming Interface?  Nick, this should be great for the Village
> Pragmatist.

I like "control surface":

https://en.wikipedia.org/wiki/Audio_control_surface
https://en.wikipedia.org/wiki/Flight_control_surfaces

It's still jargonal, but it does span a few domains.

--
glen e. p. ropella, 971-255-2847, http://tempusdictum.com
http://meat.org


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Arlo Barnes]

For either phrase, either assume your audience knows what you are talking about or define the terms before you go on. Explain that it is like a control panel you can receive data from and send instructions through, and being so generally defined does not go into details of implementation.
-Arlo James Barnes

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Owen Densmore]

Agreed.  In unix command line pipe terms, the API is the goes-into-goes-outof (gozintagozouta) GIGO? for the library.  This is how Sun engineers talked with management about new projects and indeed became a buzzword.

TL;DR

Actually, if you include the unix command arguments, you get a lovely example of a Turing model: input, state, output.

   -- Owen

On Sat, May 4, 2013 at 5:22 PM, Arlo Barnes <[hidden email]> wrote:

For either phrase, either assume your audience knows what you are talking about or define the terms before you go on. Explain that it is like a control panel you can receive data from and send instructions through, and being so generally defined does not go into details of implementation.
-Arlo James Barnes

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Dale Schumacher]

I prefer the term "protocol".  It encompasses the medium, the format, the expectations/assumptions and the potential dialog among the participants.

On Sun, May 5, 2013 at 11:22 AM, Owen Densmore <[hidden email]> wrote:

Agreed.  In unix command line pipe terms, the API is the goes-into-goes-outof (gozintagozouta) GIGO? for the library.  This is how Sun engineers talked with management about new projects and indeed became a buzzword.

TL;DR

Actually, if you include the unix command arguments, you get a lovely example of a Turing model: input, state, output.

   -- Owen

On Sat, May 4, 2013 at 5:22 PM, Arlo Barnes <[hidden email]> wrote:

For either phrase, either assume your audience knows what you are talking about or define the terms before you go on. Explain that it is like a control panel you can receive data from and send instructions through, and being so generally defined does not go into details of implementation.
-Arlo James Barnes

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Stephen Guerin]

I'm seeing a rise in the use of "endpoints". Eg REST, SOAP and WMS endpoints

On May 10, 2013 8:00 AM, "Dale Schumacher" <[hidden email]> wrote:

I prefer the term "protocol".  It encompasses the medium, the format, the expectations/assumptions and the potential dialog among the participants.

On Sun, May 5, 2013 at 11:22 AM, Owen Densmore <[hidden email]> wrote:

Agreed.  In unix command line pipe terms, the API is the goes-into-goes-outof (gozintagozouta) GIGO? for the library.  This is how Sun engineers talked with management about new projects and indeed became a buzzword.

TL;DR

Actually, if you include the unix command arguments, you get a lovely example of a Turing model: input, state, output.

   -- Owen

On Sat, May 4, 2013 at 5:22 PM, Arlo Barnes <[hidden email]> wrote:

For either phrase, either assume your audience knows what you are talking about or define the terms before you go on. Explain that it is like a control panel you can receive data from and send instructions through, and being so generally defined does not go into details of implementation.
-Arlo James Barnes

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[glen ep ropella]

On 05/10/2013 07:04 AM, Stephen Guerin wrote:
> I'm seeing a rise in the use of "endpoints". Eg REST, SOAP and WMS endpoints

Do you mean in the sense of leaves of a graph?

--
glen e. p. ropella  http://tempusdictum.com  971-255-2847

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Grant Holland]

Each of these terms (API, protocol, endpoint) often connotes different
expectations about the relationships and responsibilities of the
participants. For example, is there expected to be asymmetric
responsibilities (e.g. client-server) between them?, What about any
implied "contract" between them? What about cardinality (APIs are
generally one-to-one, whereas endpoints may be many-to-one, e.g publish
and subscribe). What about the potential for concurrency?

So there are many considerations and properties that each of these may
imply or for which there may be differentiating expectations based upon
the milieu in which each originated (OOP, network communications,
distributed objects, etc.).

In other words, the usage of these terms is not really interchangeable.

On 5/10/13 8:09 AM, glen e p ropella wrote:
> On 05/10/2013 07:04 AM, Stephen Guerin wrote:
>> I'm seeing a rise in the use of "endpoints". Eg REST, SOAP and WMS endpoints
> Do you mean in the sense of leaves of a graph?
>


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[scaganoff]

I prefer the term "service" as in service-oriented architecture but unfortunately that term has become so aligned with the nightmare complexity of web-services that the term is distinctly unfashionable. But a standalone, autonomous, platform-neutral, re-usable, location-independent function is a service - regardless of whether is it REST or SOAP or CORBA or whatever.

API has come to mean a publicly exposed function (or set of functions) that are usually REST, but sometimes SOAP and usually some form of XML or JSON over HTTP. These APIs are nonetheless services.

I've seen endpoint used as a synonym of API, but within the SOA paradigm and endpoint is an instance of a service running at some physical location specified by a URL. So two instances of the same service (e.g. weather forecast) might be available at two endpoints.

Protocol is more problematic since it is used in a lot of places to mean a lot of things. I'd prefer not to overlay it even more as a synonym for API or service.

Regards,
Saul

On 11 May 2013 00:22, Grant Holland <[hidden email]> wrote:

Each of these terms (API, protocol, endpoint) often connotes different expectations about the relationships and responsibilities of the participants. For example, is there expected to be asymmetric responsibilities (e.g. client-server) between them?, What about any implied "contract" between them? What about cardinality (APIs are generally one-to-one, whereas endpoints may be many-to-one, e.g publish and subscribe). What about the potential for concurrency?

So there are many considerations and properties that each of these may imply or for which there may be differentiating expectations based upon the milieu in which each originated (OOP, network communications, distributed objects, etc.).

In other words, the usage of these terms is not really interchangeable.

On 5/10/13 8:09 AM, glen e p ropella wrote:

On 05/10/2013 07:04 AM, Stephen Guerin wrote:

I'm seeing a rise in the use of "endpoints". Eg REST, SOAP and WMS endpoints

Do you mean in the sense of leaves of a graph?

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

--
Saul Caganoff
Enterprise IT Architect
Mobile: [phone]
LinkedIn: http://www.linkedin.com/in/scaganoff

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Robert J. Cordingley]

What about doorway?  Some doors are easily opened, some require a key, some open up to a new world.  Depending on the audience (the suggestions was it was for lay people) the allegories may work quite well.

Robert C

On 5/10/13 11:55 PM, Saul Caganoff wrote:

I prefer the term "service" as in service-oriented architecture but unfortunately that term has become so aligned with the nightmare complexity of web-services that the term is distinctly unfashionable. But a standalone, autonomous, platform-neutral, re-usable, location-independent function is a service - regardless of whether is it REST or SOAP or CORBA or whatever.

API has come to mean a publicly exposed function (or set of functions) that are usually REST, but sometimes SOAP and usually some form of XML or JSON over HTTP. These APIs are nonetheless services.

I've seen endpoint used as a synonym of API, but within the SOA paradigm and endpoint is an instance of a service running at some physical location specified by a URL. So two instances of the same service (e.g. weather forecast) might be available at two endpoints.

Protocol is more problematic since it is used in a lot of places to mean a lot of things. I'd prefer not to overlay it even more as a synonym for API or service.

Regards,
Saul

On 11 May 2013 00:22, Grant Holland <[hidden email]> wrote:

Each of these terms (API, protocol, endpoint) often connotes different expectations about the relationships and responsibilities of the participants. For example, is there expected to be asymmetric responsibilities (e.g. client-server) between them?, What about any implied "contract" between them? What about cardinality (APIs are generally one-to-one, whereas endpoints may be many-to-one, e.g publish and subscribe). What about the potential for concurrency?

So there are many considerations and properties that each of these may imply or for which there may be differentiating expectations based upon the milieu in which each originated (OOP, network communications, distributed objects, etc.).

In other words, the usage of these terms is not really interchangeable.

On 5/10/13 8:09 AM, glen e p ropella wrote:

On 05/10/2013 07:04 AM, Stephen Guerin wrote:

I'm seeing a rise in the use of "endpoints". Eg REST, SOAP and WMS endpoints

Do you mean in the sense of leaves of a graph?

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

--
Saul Caganoff
Enterprise IT Architect
Mobile: [phone]
LinkedIn: http://www.linkedin.com/in/scaganoff

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com