① web項目給這樣的介面，我不清楚怎樣做，如果是前端提交，那獲取的數據到哪裡了，如果用java代碼怎麼提交
有2個建議，1.把邏輯思路理順了再提問題，2.多把request 與 response 之間的基礎知識打好，畢竟，現在 前端HTML(vue等等框架) + 後端 API 聯合開發，這個都弄不清楚怎麼搞？
現在來解決可能遇到的問題
前端框架接收 不需要創建接收對象，js屬於弱類型，var 直接可以接收對象
後端接收，從調用開始，創建 HttpRequest對象， 對象里設置param參數,設置Content-Type 傳輸類型，Send後創建HttpResponse 接收，接收對象為stream流，根據此流轉成數據對象類，返回介面中對象類有headers，statusCode，statusCodeValue，body,比如headers，body為不固定參數，可以設置成（T）類型
② 實際中前後端開發數據交互是怎麼樣的
1.前端請求數據URL由誰來寫?
在開發中,URL主要是由後台來寫的,寫好了給前端開發者.如果後台在查詢數據,需要藉助查詢條件才能查詢到前端需要的數據時,這時後台會要求前端提供相關的查詢參數，這里的查詢參數也就是URL請求的參數。
2.介面文檔主要由誰來寫?
介面文檔也是主要由後台開發者來寫的,因為直接跟數據打交道的就是後台,後台是最清楚,資料庫裡面有什麼數據,能返回什麼數據.前端開發只是數據的被動接受者.所以介面文檔也主要是由後台來完成的,前端只是介面文檔的使用者,使用過程中,發現返回的數據不對,則需要跟後台進行商量,由後台來修改.切記 前端不要隨意更改介面文檔,除非在取得後台開發人員的同意的情況下.總的來講,介面文檔主要由後台來設計,修改,前端開發者起到了輔助的作用。
3.前端開發與後台交互的數據格式主要是什麼?
主要是JSON
XML現在用的不多
4.前端開發的後台交互原理？
在項目的時候，我們前後端會大概說一下介面地址，前端請求的參數，後端返回的參數，然後大家就開始寫，寫的差不多的時候，大家調一下介面看一下返回的數據，沒問題就可以了。
5.前端請求參數的形式
GET和POST兩種方式
對安全性不高 採用get方便
post要比get安全
GET - 從指定的伺服器中獲取數據
POST - 提交數據給指定的伺服器處理
6.前端應該告知後台哪些有效信息,後台才能返回前端想的數據的呢?
先將要展示的頁面內容進行模塊劃分，將模塊的內容提取出來，以及方便前端的一些標志值等，將所有想要的內容和邏輯告知後端，
後端就會去資料庫裡面去查找相應的數據表中去獲得相應的內容，或者圖片地址信息。
URL中的參數主要是根據後台需要,
如果後台需要一個參數作為查詢的輔助條件 前端在URL數據請求時就傳遞參數。
參數前面？
幾個參數中間&
7.我們應該怎麼把頁面這些信息有效傳達給後台,以及後台是如何獲取到這些數據?
總的來講:所有前端請求的URL後面的參數,都是輔助後台數據查詢的.如果不需要參數,那麼後台就會直接給個URL給前端。
8.前端應該如何回拒一些本不屬於自己做的一些功能需求或任務?
在與後台打交道中,我們經常遇到這種情況,有時候明明後台來處理某個事件很簡單,後台非要你來做,這時候我們應該懂得去回絕他。
原則:前端就是負責把數據展示在頁面上
發揮:這就需要我們對一個需求,一個任務的要有清晰認識了,如果對任務含糊不清,自己都沒搞明白,你只能受後台擺布了.最後也會因為任務沒有完成而備受責難了。
9.當前端在調用數據介面時,發現有些數據不是我們想要的,那麼前端應該怎麼辦呢或者怎麼跟後台講呢?
首先要把請求的URL和返回的數據以及在頁面的展示的情況給跟後台看,這樣有理有據,後台開發人員是不會說什麼的,否則,後台會很不耐煩的,甚至罵你的可能都有,本身做後台比較難,尤其在查詢數據,取數據,封裝數據方面都比較難處理。
10.為什麼需要在請求的時候傳入參數？
因為後台在查詢資料庫的時候需要條件查詢。
③ 在頁面上修改某個欄位時,如何在提交時判斷該欄位有沒有被修改過
常見方法有兩種：
一、在客戶端操作。
1 對頁面原始值進行保存。
2 提交時，獲取當前值。
3 用當前值與原始值進行對比。如果相同則表示沒修改過。
二、在伺服器端操作。
1 發送頁面時不做任何處理。
2 提交時發送當前頁面所有內容。
3 在伺服器端拿到新數據後，再次讀一次資料庫，然後逐個欄位進行對比。如果完全相同，表示沒有修改過。
④ 本人後台開發，前端說改個東西要兩天，但我感覺撐死2小時，怎麼辦
本人有五年前台開發經驗，2年後台開發經驗，實際上我覺得後台可能比前台還要容易，在不考慮比較深的技術壁壘的情況下，前台有原型圖，我需要百分百還原，再加上畫面特效，用戶操作特效等挺麻煩的，有時候一個小小的點卡半天很正常，只要不是特別簡單的需求，說隨便兩個小時搞好的我是不怎麼相信的。轉後台之前，本來以為很難，結果後台寫起來真的就是好快，我經常做到無聊到沒事做把人家的活攬過來一起做，後來還是前後台一起搞了，後台框架搭好以後，剩下的只是業務介面實現而已。總的來說，前台入手容易精通難，後台更多偏向框架的靈活使用。不要瞧不起前台，特別是某些後來開發人員覺得不就是寫個界面么？但我想說界面的邏輯不比後台簡單，前幾年曾經去參加一個公司的面試，以後後開發人員跟我在那裝，一個勁的說就是前台而已，很簡單的事情，說了好多次，把我說煩了，我就跟他探討前後台，屁都不懂的面試官，就一新生蛋子，最後我說你公司連面試官都這水平，與我期望不符合，要過來簡歷就撤了，帶著有色眼鏡看待技術的人一般都是那種一知半解，一瓶子不滿，半瓶子晃悠的人
我就是做前端開發十年了，其實你這個問題在職場中普遍存在。就像以前我認為，後端不就寫寫介面，一個介面10幾分鍾的事情，墨跡個半天沒出來一樣，總是很埋怨，其實你真正去實操的時候，發現並沒有這么簡單，細節的東西特別多。
前端說需要兩天時間，可能考慮某些改動涉及會影響到其它功能方面的問題，都需要測試評估，並且前端的開發，比後端還多了界面這一塊開發的時間，這界面調試往往最費時間，這是很多後端開發人員沒有考慮到的。
總之，前端評估可能是一個相對寬泛並且預留了一定空間的時間，也許他能答應2小時做完，但能保證真的做好了嗎，沒有隱患問題存在，這些都是要考慮的，畢竟前端一發布出去就不好在升級版本改動了，這也就是他和你評估時間存在較大差異的一個重要原因吧！
圖一，安裝完oracle,sql,db,mysql後，負責資料庫開庫的叫做底層，
圖二，負責瀏覽器視窗頁面上能看見的什麼東西的一律叫前端。
圖三，負責整個視窗界面看起來很舒服，給人留下深刻印象的我們一般叫他們ui.
項目經理拿到項目，會給底層大致講解一下，然後底層會根據講解開庫做系統，然後給前端代碼。前端拿到代碼寫入頁面然後整個系統大致完成，接著ui介入，ui根據客戶需求制定界面，再轉回前端，雙方共同負責界面達成。接著就輪到測試上場了。一般測試的外號文雅點叫清道夫，難聽點叫擦屁股的。然後高端大氣上檔次的就是全棧工程師了。在測試過程中負責整個系統測試，運行，並找出各個部位的bug,並修復它，然後寫出報告，報告將直接提交人事或者財務，根據描述部位對相應人員做出處罰。
這就是軟體設計部門的整個工作流程。所以，你說後台開發對前端有疑問，就有點納悶。前端有問題，和你後台開發什麼關系？
至於什麼後台開發。。。。。好像外包公司起這名的比較多。
首先問題要分幾面來看。
會者不難，難者不會。
要看別人的具體經驗，具體技術水平。
每個人做同一件事花的時間是不一樣的，不要把自己的想法強加給別人。
如果別人認為你應該怎麼怎麼樣，你也會反感。
而且前端要2天，項目經理能給，就說明前端說的在理。
如果你覺得2小時可以幹完，說明你能力強，但作為同事，還是要善良一些，你總不能有活就幫他干。
也許他干幾次之後，效率就上來了，從兩天變一天，再變成2小時呢。
人是要進步的，是要學習的。
多站在對方的角度思考問題，也許你就有一個不一樣的答案。
最後祝工作開心順利！
在工作中遇到這種人很正常，這種人就是大家口中的「磨洋工」。
有些人認為前端和後端不一樣，後端改個需求可能一個小時就可以搞定，前端復雜，需要一天或者更長時間，這完全是胡扯，是消極工作的一種變現。有些程序員就是喜歡將工作難度誇大，明明一個小時的工作量，他非的要評估一天的工作量。這對於非技術人員可能感覺不到，但是對於一起開發的技術人員來說，一眼就能看透工作量，只是同為同事，大家不好說破而已。
三天100行代碼的奇葩同事曾經碰到過一個前端同事，技術很一般，分配給的任務，不管是小到一個css樣式的調整還是一個完整的功能模塊，讓他評估時間，最少需要一天。曾經有一次一個簡單。需求評估，後端同學評估只需要半天時間，他的前端竟然需要三天時間，讓他說出具體工作的難度在哪裡，他卻支支吾吾說不出來。這三天的時間我時不時觀察他，發現他一天大半的時間都在瀏覽網頁，要不就是微信群各種聊。三天過去了，我去看了一下他提交的代碼行數，不到100行！三天時間寫了不到100行代碼！
所以，有些程序員就喜歡磨洋工，當然，也有可能是考慮的比較全面，追求代碼質量。 如果碰到這種情況，只要他評估的時間在產品可以接受的時間范圍內，那你也就無所謂。如果你是一位研發負責人，請他將工作進行拆分評估，具體到功能點的時間，看他這兩天時間是如何分配的？炸一炸他，他總能露出破綻。
首先，個人不太理解，為什麼一個後端開發的程序員需要控制前端程序員的開發時間？不管前端需要多少時間，到底是2小時還是2天，這個不應該是由產品經理或者項目負責人來控制的么？
有時候不在其位不謀其政，作為後端程序員可以提出自己的疑問，但是到底如何布置任務和排期，還是交給負責人來協調吧。程序員之間沒有必要相互對立，特別還是因為一個自己並不擅長的領域相互產生矛盾。
當然，如果你自己除了是後端開發外，還兼職了項目負責人，那確實可以對前端的研發時間進行評審。如果你和前端對於某個功能的時間評估上出現分歧，那麼可以採用以下這些方法。
可以考慮「功能點分析」讓前端把功能分解若干個功能點，然後對每個功能點都採用樂觀時間進行評估，最後匯總後在增加30%的Buffer。
例如：我現在要做一個訂單頁面，這個訂單頁面有查看訂單列表、查看訂單詳情、取消訂單、確認收貨、評價幾個功能。
畫一個思維導圖，然後每個功能再往下分解。查看訂單列表包括了ajax請求api獲取數據，組裝table，css考慮已有框架的樣式復用，不另算時間；詳情頁的話，也包括了ajax請求api，頁面的html和css等等等等（細分的力度自己掌握）。
最後，所有的功能點被一一列舉出來以後，就挨個分析，哪個哪個需要幾個小時，最終就可以匯總出時間了。這里可能需要注意一下，單一的功能點，其實大致已經可以評估得到代碼量了，只要不是特別復雜的演算法類功能點，大部分都可以把時間精確到小時甚至0.5小時。而且，這里我們採用樂觀評估的方法，就是說，大家別去想這個功能可能有坑，可能如何如何。最後匯總時間後，給予總體的Buffer量來抵禦風險。
當然，也可以使用「對照分析」的方法我們可以考慮對照曾經做過的類似功能或類似優化，當時的那個功能花費了多少時間，而這次相比上次的差異是哪些？是會花費更多時間，還是更少時間。這樣，就能夠得到一個大致的完成時間了。
這種評估方式，就只是針對於當前的功能曾經有過經驗，時間上有參考價值的情況下。不能把完全不相乾的兩個功能拿來類比。而我們在評估的時候，就只需要考慮差異部分的評估，大大的減少需要評估的內容。
最後，就是「專家評估」了如果你對於前端確實也比較了解，自己完全能夠獨立完成這個工作任務，時間花費可以測算的話，你其實就可以作為一個「專家」的角色了。那麼，你評估的時間就是大家必須要遵循的時間。當然，這種方式需要你有絕對的權威性，不然就是 搞笑 。
不管使用什麼方式，對於分歧問題的處理其實都比較機械，並不是非常的利於團結，最好的方法還是大家商商量量的把事情給解決了。
這個問題需要多緯度去分析：
其實本質就是要麼你判斷錯誤，要麼是你同事判斷錯誤。
無論是你對還是你錯，這工作都是由別的同事來完成的，你沒必要太過於關心，你沒必要太過於在意。
但是，假如這個工作和你的工作有關聯，這個工作的完成時間，完成質量，會影響到你的工作進展與工作質量，那麼你必須要恰當的參與進去，你需要：
這個很重要，同事之間工作上的溝通交流還是必須的，交流內容可以由淺入深，先從你認為只需要2小時就完成的工作談起，然後逐漸深入進去，多聽聽同事的解釋，當然你也可以發表你的意見。互相理解，互相體諒，互相幫助，最好能達成一致。
如果工作非常緊急，你這個同事也不配合你，那你只能請領導出面進行協調。當然，你要有理有據，只針對工作不要針對人。
最後建議：
如果不是領導，那麼就不要參與不要議論別人的工作。
如果沒得到允許，那麼就不要參與不要議論別人的工作。
這個我倒是有心得可以分享。其實如果做程序員的或多或少都會遇到這樣的現象，要不你就是問題中的後台開發，要不就是改東西需要兩天的前端。我覺得都很正常啊，畢竟你不是對方，你也不知道對方有什麼想法和困難。
像產品給個需求給到開發，一般說改這個東西要多久，開發看了下進度表，思考了一會後給了個時間點，這時候一般產品不會多問，因為他不知道實際開發難度，而且他也不知道開發的其他需求進度，所以不敢多說，反正開發給了排期，在合適的項目進度內也就ok。
但如果是開發對開發，那就出現問這個問題的情形，開發A要給開發B提個需求，然後開發A實際內心有個預期感覺這個需求能在其他事情不幹擾下多久完成。注意！是其他事情不幹擾下的情況，其次，這是開發A按自己的能力評估，不是按開發B的能力評估的，而且這種事情一般不是遇到自己，便潛意識就把需求想得比較簡單，畢竟大家都容易「寬於待己，嚴於待人「。
在這種前提下，實際開發B可能本身就有其他優先順序高的需求要做，其次這件事情可能牽涉到系統內部其他需要修改的地方，會牽一發而動全身，不是後端想像修改單個頁面就可以完成的那麼簡單。
所以這種情況開發A說的2個小時是一種自我想像的事情，要不等前端找後台開發說，這個需求最多就2個小時就可以完成，就改個介面，新增這些數據POST出來就行，那我估計這個問題轉換下角色我又可以再回答一次了哈哈。
對於一個技術團隊來說，配合默契是非常重要的，特別是前端和後端人員，如何做到默契，需要三點：
一、前端要懂後端，後端要懂前端，只要這樣，大家才能無縫對接；
二、對工作的重視，無論你負責哪個環節，只要有這個態度，項目會順利的進行下去；
三、同事之間的關系，這很重要，千萬不要有互相拆台的行為：這其中有個人的人品問題，也有個人交際情商問題，這個比較難以處理。
回到你的問題，你認為2小時的工作量，但你同事卻說需要兩天，這種矛盾的可能性比較多，但不管是什麼情況，你都要本著和同事維護好關系為基礎，要主動理解同事，哪怕他說的是錯的，你就會釋然了。
你兩小時能完成人家兩天的工作量，產出是人家八倍！！！那你是不是可以跟你的領導建議下，把前端的任務交給你，讓老闆給你開這個前端雙倍的工資，你承諾產出比現在的前端多4倍，然後你每天只要干4小時活就能完成任務。
多贏局面啊：
1、服務端工資再高也不可能比前端兩倍還多，現在前端都不便宜！你大幅漲薪了，而且每天工作時間少一半，你賺大了；
2、老闆少花了一半的錢、產出卻擴大了一倍，老闆賺大了；
3、那個可憐的前端可以讓他滾蛋了…
希望這個辦法能讓你們公司長命百歲
⑤ 前端請求介面報fail api 什麼意思
請求失敗。前端請求介面報failapii是請求失敗的意思，就是你請求訪問的這個資源內容伺服器無法返回給你，無法顯示你想要的內容，把介面數據更改就可以了。
⑥ 前端埠是怎麼交互後端
隨著互聯網的高速發展以及IT開發技術的升級，前後端分離已成為互聯網項目開發的業界標准使用方式。在實際工作中，前後端的介面聯調對接工作量佔Web前端人員日常工作的30%-50%，甚至會更高。
首先我們要知道為什麼前後端要交互
為什麼要前後端分離？
把前端與後端獨立起來去開發，放在兩個不同的伺服器，需要獨立部署。兩個不同的工程，兩個不同的代碼庫，不同的開發人員，前後端工程師需要約定交互介面，實現同步開發。開發結束後需要進行獨立部署，前端通過介面來調用調用後端的API，前端只需要關注頁面的樣式與動態數據的解析和渲染，而後端專注於具體業務邏輯。
前後端分離的優點是什麼？
1、徹底解放前端。前端不再需要向後台提供模板或是後台在前端HTML中嵌入後台代。
2、提高工作效率，分工更加明確。前端只關注前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將數據寫死或者調用本地的JSON文件即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。
3、局部性能提升。通過前端路由的配置，我們可以實現頁面的按需載入，無需一開始載入首頁便載入網站的所有的資源，伺服器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。
4、降低維護成本。通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及調試，代碼重構及可維護性增強。
5、實現高內聚低耦合，減少後端（應用）伺服器的並發/負載壓力。
6、即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，但無法提供數據。
7、可以使後台能更好的追求高並發、高可用、高性能，使前端能更好的追求頁面表現、速度流暢、兼容性、用戶體驗等。
了解了這些，我們再來看前後端是怎麼實現交互的
前端調用後端介面無外乎六種方法，如下：
1、打開vs，創建空的asp.net mvc演示項目【WebMVC】
（1）依次點擊【文件】->【新建】->【項目】；
（2）在【新建項目】界面選擇【Web】->【ASP.NET Web 應用程序(.NET Framework)】，輸入名稱，選擇框架至少4.5版本，點擊【確定】按鈕；
（3）選擇【空】->【MVC】->【確定】 ；
（4）創建好了項目。
2、在項目中
（1）在Controllers文件夾上點擊滑鼠右鍵，依次選擇【添加】->【控制器】，即可完成HomeController的創建；
（2）在Controller的Index方法內，點擊滑鼠右鍵，選擇【添加視圖】；
（3）在項目中添加文件夾【Content】並添加jquery源文件；
（4）在Index頁面添加jquery的引用。
3、在Index頁面中添加一個輸入文本框，一個按鈕，以及顯示結果的dom。
4、在HomeController中添加新的方法，用於接收前台傳入的參數，組裝後返回。
5、在Index頁面，添加Jquery的ajax方式，調用後台介面，返回結果的處理代碼。
6、在vs中，按F5調試運行結果，如下：
（1）在文本框中輸入內容；
（2）點擊按鈕，調用介面，並將返回值顯示在界面；
（3）如果要提交大量數據，或者敏感數據，請修改ajax的type方式，這樣參數就不會在url地址欄中顯示了。
以上回答，希望對你有所幫助