February 9, 2012 at 12:04 am
Comments posted to this topic are about the item API Changes
February 9, 2012 at 3:34 am
I have always seen my job as a programmer more akin to an enabler. I haven't always described it in those terms but always with the same meaning. I would even argue that, whilst being more central to the real business needs, data is just another enabler. Businesses need to perform some tasks in order to make money. These tasks usually require data and a method of accessing it, possibly modifying it.
IT is just a means to an end: Without the business there are no sales. No sales means no data capture, storage and reporting. All of our tasks are to enable the business to carry out the duties of that business. Clearly as advances in techniques and technology have been applied new ways to improve the performance of the business have been achieved. But always, it is about the business.
As for Enterprise APIs, are they just a different perspective on or, perhaps, access mechanism to the Enterprise Service Bus (ESB)? Is this driven by more businesses requiring what has been called Data Mashups? This has been the way on trading floors for a long time. Is this not businesses just realising that they can utilise ALL their data in various combinations for productivity and/or efficiency improvements?
I think so.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 9, 2012 at 3:43 am
I have recently gotten deeply involved in Web Services technology. This is all about Data API with data moving across the Internet/Intranet from and to heterogeneous technologies. I must say the complexity of it all is a bit frightening.
February 9, 2012 at 11:54 am
". . . Think about providing APIs as you develop software inside yout company, rather than just assuming you'll build all the functionality needed."
I am afraid it is a business decision that has to be made at least two levels above my head, and I would have to have a good explanation if I did it on my own.
February 9, 2012 at 1:19 pm
I read something once about using APIs as Standard Operating Procedure that stills makes alot of sense to me.. "Even if all APIs were standardized, there would still be a need for integration. Why? APIs are only one end of the equation – they do not complete the end-to-end integration process between applications. Two apps with APIs still need a cord with plugs to connect them together." 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
February 9, 2012 at 2:58 pm
TravisDBA (2/9/2012)
I read something once about using APIs as Standard Operating Procedure that stills makes alot of sense to me.. "Even if all APIs were standardized, there would still be a need for integration. Why? APIs are only one end of the equation – they do not complete the end-to-end integration process between applications. Two apps with APIs still need a cord with plugs to connect them together." 😀
Uhm... no. The cord would be a third app. In my experience typical use of APIs is one app using another one for some specific purpose, e.g., a data entry form using Office spellchecker.
February 10, 2012 at 12:25 am
Revenant (2/9/2012)
TravisDBA (2/9/2012)
I read something once about using APIs as Standard Operating Procedure that stills makes alot of sense to me.. "Even if all APIs were standardized, there would still be a need for integration. Why? APIs are only one end of the equation – they do not complete the end-to-end integration process between applications. Two apps with APIs still need a cord with plugs to connect them together." 😀Uhm... no. The cord would be a third app. In my experience typical use of APIs is one app using another one for some specific purpose, e.g., a data entry form using Office spellchecker.
...unless of course the API was plugged into an ESB!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 10, 2012 at 2:07 am
We collects data by export-import tools based universal and custom API ,done deep analyse them, prepare sheets and recommendations, satisfy business and yourself. How we dance next?!)
February 10, 2012 at 7:42 am
Revenant (2/9/2012)
TravisDBA (2/9/2012)
I read something once about using APIs as Standard Operating Procedure that stills makes alot of sense to me.. "Even if all APIs were standardized, there would still be a need for integration. Why? APIs are only one end of the equation – they do not complete the end-to-end integration process between applications. Two apps with APIs still need a cord with plugs to connect them together." 😀Uhm... no. The cord would be a third app. In my experience typical use of APIs is one app using another one for some specific purpose, e.g., a data entry form using Office spellchecker.
Dude, it's called an analogy. You know what they are? Also, enterprise level API's have gotten a little more complex in recent years than your average spellchecker API. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
February 10, 2012 at 9:21 am
TravisDBA (2/10/2012)
Revenant (2/9/2012)
TravisDBA (2/9/2012)
I read something once about using APIs as Standard Operating Procedure that stills makes alot of sense to me.. "Even if all APIs were standardized, there would still be a need for integration. Why? APIs are only one end of the equation – they do not complete the end-to-end integration process between applications. Two apps with APIs still need a cord with plugs to connect them together." 😀Uhm... no. The cord would be a third app. In my experience typical use of APIs is one app using another one for some specific purpose, e.g., a data entry form using Office spellchecker.
Dude, it's called an analogy. You know what they are? Also, enterprise level API's have gotten a little more complex in recent years than your average spellchecker API. 😀
Yes, I heard that mentioned. 😉
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply