目前只剩下JBI（Jo bi i）

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

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

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

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

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

我只想說
大家都太認真了

總裁你說是不是

1. 他指的BOSS應該是主管的主管之類的人.
2. API? 以他所描述的內容比較像FUNCTION之類的.其實名詞我也常常搞不清楚差異點在哪, 我都只管"它"能做啥而很少管"它" 叫做啥.

什麼I的？
我只知道我的BMI爆表啦！

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

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

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

API 就 Application Programming Interface

規範Message in,Message out

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

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

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

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

沒參加討論...

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

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

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

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

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