iT邦幫忙

9

一個API各自表述

這兩天邦裡比較熱鬧的話題,一篇關於API的.
我覺得現在一些人,專有名詞使用較不精確.
往往會有雞同鴨講的現象.

有些邦友發問時,也有表達不夠清楚的現象,例如那篇裡面,
到底Boss跟直屬主管,是同一人抑或不同人?

所指的API,是什麼??

到現在整個還是一團模糊.然後又覺得其他邦友誤會.

這也是很多來發問的人常犯的,回答問題的邦友,又沒特異功能,
哪能知道貴公司內部的情況.
像是有些來問SQL Command要怎樣解,然後Table長什麼樣,
資料也沒有,這樣子實在很難幫上忙啊.
有些來問網路問題的,也沒把環境描述清楚,大家往往都要再問,
然後才逐步的有些線索.

還是先想想怎樣好好的描述問題吧.


0
外獅佬
iT邦大師 1 級 ‧ 2015-03-12 11:14:27

目前只剩下JBI(Jo bi i)落寞

那我還是拿出老梗

EDI (一底哀)

一尾 iT邦研究生 1 級 ‧ 2015-03-13 17:47:48 檢舉

iT邦幫忙MVPwiselou提到:
下JBI(Jo bi i)

是偶像劇嗎

https://www.youtube.com/watch?v=F8WDdtuaZUk

0
總裁
iT邦好手 1 級 ‧ 2015-03-12 11:24:37

幫您補上原PO
寫過API的各位,你們認為開發了API就會讓程式變得更好寫嗎?
在她還沒刪掉之前,都可以看的到...偷笑

0
darkskyline
iT邦新手 3 級 ‧ 2015-03-12 11:27:06

總裁要截圖啦,要不然刪掉了看不到了~哈哈

0
海綿寶寶
iT邦大神 1 級 ‧ 2015-03-12 11:27:18

其實那篇我有在 follow
只是沒參與討論

因為
一開始我就覺得那是一個沒意義的問題
而事後發現
提問人也並不是真的在「問」問題(因為他已經有自己的答案了)

不是技術專業的討論
逐漸走向純嗑牙,甚至筆戰

我只想說
大家都太認真了

總裁你說是不是
疑惑

看更多先前的回應...收起先前的回應...

他是希望大家肯定他的答案, 但這邊大多是老資格的人, 恩 看事情的角度不一樣了..哈哈

darkslayer提到:
這邊大多是老人

失神落寞暈

尼克 iT邦高手 1 級 ‧ 2015-03-12 14:10:07 檢舉

iT邦幫忙MVPantijava提到:
因為他已經有自己的答案了

對,他自己已經有先入為主看法囉!

總裁 iT邦好手 1 級 ‧ 2015-03-12 15:22:47 檢舉

總裁你說是不是

是不是...無言
(海綿寶寶是要我說這三個字嗎疑惑)

cdfu提到:
海綿寶寶是要我說這三個字嗎

對啦對啦
不耐煩

0
darkslayer
iT邦好手 1 級 ‧ 2015-03-12 12:00:07
  1. 他指的BOSS應該是主管的主管之類的人.
  2. API? 以他所描述的內容比較像FUNCTION之類的.其實名詞我也常常搞不清楚差異點在哪, 我都只管"它"能做啥而很少管"它" 叫做啥.
0
Samと可樂快跑
iT邦研究生 1 級 ‧ 2015-03-12 14:39:09

什麼I的?
我只知道我的BMI爆表啦!

好!讓我們欣賞一下wiki的說明:
『應用程式介面(英語:Application Programming Interface,簡稱:API),又稱為應用編程介面,就是軟體系統不同組成部分銜接的約定。由於近年來軟體的規模日益龐大,常常需要把複雜的系統劃分成小的組成部分,編程介面的設計十分重要。程式設計的實踐中,編程介面的設計首先要使軟體系統的職責得到合理劃分。良好的介面設計可以降低系統各部分的相互依賴,提高組成單元的內聚性,降低組成單元間的耦合程度,從而提高系統的維護性和擴充功能性。』
so……有時候我覺得不是觀察或是程式的問題,而是……中文學得不夠好。

最後一行有錯字:
「so……有時候我覺得不是觀『察』或是程式的問題,而是……中文學得不夠好。」
應該是:
「so……有時候我覺得不是觀『念』或是程式的問題,而是……中文學得不夠好。」

0
賽門
iT邦超人 1 級 ‧ 2015-03-12 15:32:44

想到這本書: Programming Windows with MFC...1337頁。

現在一堆人,連API是什麼都搞不清楚,就在侉侉而談....偷笑

0
pantc328
iT邦研究生 1 級 ‧ 2015-03-12 15:39:50

API 就 Application Programming Interface

規範Message in,Message out

不一定 Function call
Web Service
還由 URL
等都是

告訴你功能是什麼,怎麼傳參數,什麼收參數

pantc328 iT邦研究生 1 級 ‧ 2015-03-12 15:42:57 檢舉

pantc328提到:
Interface

就是契約
就是方法,參數地宣告

你只要照格式用,不用知道內部的實作,就能達到預期的結果
契約也代表雙方協議,不會變動
內部實作演算法會變,界面不變
這樣才不會甲方隨便變更,乙方程式莫名其妙掛掉

0
門神JanusLin
iT邦超人 1 級 ‧ 2015-03-12 16:23:22

"如何的提問"
這是一門高深的學問

我正在找我的四個朋友看著地球 ~~~

尼克 iT邦高手 1 級 ‧ 2015-03-12 16:41:16 檢舉

iT邦幫忙MVPjanuslin提到:
"如何的提問"

讚

總裁 iT邦好手 1 級 ‧ 2015-03-12 16:51:20 檢舉

看完可以把自拍照送我嗎??...謝謝

cdfu提到:
自拍照送我嗎

貼門口嗎 !
OK XD

0
fillano
iT邦超人 1 級 ‧ 2015-03-13 12:21:49

沒參加討論...

不過從他的問題看起來,他們後端只是透過定義好的介面,提供資料給前端,前端大概是利用ajax取資料來呈現,或是透過angular等框架來做。

關鍵在於「誰」來定義這些API可以提供的資料。如果是後端來規劃,或是資料還必須透過介面提供給第三方,通常可能就不會定義得很複雜。不過因為客戶接觸到的是前端,而且提出的需求常常千奇百怪。這時候就會發生問題:

  1. 這些API是否只需要提供基本的資料,然後再由前端自己把資料組合運用?
  2. 或是,API要根據前端的資料需求來設計,而不是根據後端可以提供什麼資料來設計。這樣前端就比較省事。
  3. 1, 2 都做

如果只做1,前端還要花很多時間來做。而且有些需求單靠前端來做會有點困難。至於2... 這樣好像就不能叫做API了XD,也許該叫做ViewModel?

我覺得發問者的問題是,他們做了1,但是他認為對於提昇開發的速度不一定有幫助。

真想給您一個讚!! 大致上就是類似你說的情境

我們的api是用rest的方式去實作溝通的介面,整個api的定義,基本上就只是把基本資料以json或xml的格式提供給前端進行運用。

如同您所說的api是由後端來定義的,前端的需求則完全由客戶自行定義,所以它根本上是發散的。
也正因為這樣我才會質疑在那種情境下,API是不是萬靈丹。

fillano iT邦超人 1 級 ‧ 2015-03-16 11:47:04 檢舉

如果前端的資料需要join / group / 分頁 / 排序的組合,光靠簡單的API...前端會很難做XD

如果前端需求複雜而且多變化,也許該由前端提出資料需求,後端寫restful介面來支援。這不是api通常API的概念,只是基本MVC的概念(我知道也很多人叫他api,不過這其實只是V與C之間實作方法的不同,是直接render出view,還是透過ajax取view使用的資料)。

我要留言

立即登入留言