Re: [FRIAM] API alternative?

[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 > 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: +61 410 430 809
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

Re: [FRIAM] API alternative?

[Saul Caganoff]

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  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: +61 410 430 809
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

Re: [FRIAM] API alternative?

[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

Re: [FRIAM] API alternative?

[glen e p 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

Re: [FRIAM] API alternative?

[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" 
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 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 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

Re: [FRIAM] API alternative?

[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  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  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

Re: [FRIAM] API alternative?

[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  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

Re: [FRIAM] API alternative?

[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

Re: [FRIAM] API alternative?

[glen e. p. 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

[FRIAM] 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* @jashkenas
4h

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