2013-10-03 70 views
0

我正在創建一個使用第三方API(Web服務)作爲數據源的ASP.NET MVC網站。它是隻讀的,到目前爲止已被個人使用桌面應用程序訪問(大多數使用C#)。我希望通過網站使用此API來集中信息併爲用戶提供歷史信息,自動執行某些重複性任務,並更輕鬆地在用戶之間共享信息。解決代表用戶的網站請求作爲攻擊解釋請求的API

今天的桌面客戶端會遇到麻煩,如果您使用客戶端向API重複發送請求,您的IP將被限制和/或禁用。我認爲,如果我從我的網站向API提出請求,它的IP將在它看到任何重要用途時被禁止。

我們假設我無法與API所有者一起工作。解決此問題的最簡單方法可能是使用AJAX完成所有API訪問。當用戶訪問該網站時,他使用AJAX向API發出請求,然後轉向並將其發佈到我的網站。由於多種原因,我不喜歡這個想法 - 首先,它會很慢,其次,我不能保證發送到我的網站的數據是真實的。惡意用戶可能因任何原因向我發送不良信息。

所以我認爲一個更好的主意是建立一箇中間人。用戶仍然會被迫發出AJAX請求,但他們會將其轉到代理或我控制的其他東西,然後將其轉發給真實的API並攔​​截響應,以便我可以更確定一點我檢索的數據是真實的。

是否可以創建這樣的「代理」?它會帶來什麼?我想用.NET技術來做,但我願意接受任何想法。

編輯:看來我通過使用「代理」一詞造成了混淆。我不想要一個代理,我想要的是一個傳遞,允許我攔截API的響應。我可以讓客戶端發出請求,然後再上傳,但我不想信任客戶端,我想信任API。

讓我以更簡短的形式來解釋這一點。用戶計算機上有一個客戶端,可以向API發出請求以獲取當前信息。我想創建一個網站做同樣的事情,但我正在考慮API Web服務可能會注意到,雖然以前它從十個不同的IP接收到十個用戶的十個請求,但它現在正在接收十個十個請求來自一個IP的用戶並阻止該IP將其視爲機器人,儘管每個請求都是由用戶請求發起的,就像以前一樣。解決此問題的最簡單方法是讓用戶發出請求,然後將響應上傳給我,但如果我這樣做,我就會被迫盲目接受來自客戶端的數據,這對任何網站來說都是一個巨大的禁忌。 。相反,如果我可以放置將請求轉發給保存用戶IP的API,但也可以攔截響應,從而證明數據是權威的,這將是首選。然而,我想不出一個軟件機制來做到這一點 - 它似乎需要在不同的層面上完成。

至於法律方面的問題,這是一個廣泛使用的API,有許多應用程序和用戶(還有其他網站我發現使用該API),但我無法找到任何法律信息,例如服務條款超出論壇發佈在API的技術支持部分中,「不要重複請求,遵守我們的緩存說明」等。我找不到任何可能表明這是非法或錯誤使用Web服務的內容。

+2

看來這個第三方網絡服務並不打算以您希望使用它的方式使用。我不明白代理如何稱呼會有所幫助,因爲它會遇到相同的侷限性 - IP地址太少會被限制/禁止,或者您需要每個活動用戶一個代理IP地址(這聽起來很不錯站不住腳)。 – Moho

+1

我同意@Moho。至於你最初的想法,除非API所有者支持CORS,否則你無法從你的網頁向他們的API執行跨域AJAX調用 –

+0

與你想使用的Web服務的提供者一起工作。如果你無法繼續,並且無論如何你至少違反了他們的合理使用條款,並且最壞的情況是從他們那裏偷竊,從而參與犯罪活動。 – RBarryYoung

回答

1

你可以實現你的代理。它不需要是AJAX,它可能只是一個普通的網頁請求,如果你想要顯示API結果。

無論哪種方式,在.Net你可以使用ASP.Net MVC。如果您需要AJAX,請使用實現源API的Web API控制器操作,如果您需要網頁,則只需使用常規的MVC控制器/操作即可。

在控制器內部,您只需向源發出Web請求,並通過參數傳遞。

爲了避免節流,您可以緩存從服務器發出的每個請求的結果(使用普通的ASP.Net緩存),這樣如果另一個客戶端試圖發出相同的請求或類似的請求,您可以返回緩存結果而不是向API發出另一個請求。

您必須確定結果應該緩存多長時間,具體取決於客戶端數據的最新狀態。例如。對於天氣數據,緩存一個小時似乎沒問題。對於更快速移動的數據,它將不得不更少。您必須在避免節流和保持數據新鮮之間取得平衡。

您也可以在每次請求時智能獲取比您需要的數據更多的數據,然後篩選返回給客戶端的結果集。這可以給你一個更好的緩存命中率。

+0

好消息是,在進行了更多研究之後,我發現還有其他網站使用API​​,並且限制/禁止僅針對不遵從響應的API的客戶端完成,詳細說明在做出另一個之前應該等待多長時間請求相同的信息,或重複發出錯誤的呼叫。 –

+0

我接受@Mike的回答,因爲他顯然花時間寫了一個他認爲能回答我的問題的答案(雖然它太基本了 - 我已經考慮過這些東西),儘管它沒有。我要問一個單獨的問題,希望能夠更容易理解和回答。真的,感謝邁克在大多數其他人(如一些評論者)因爲至少對我而言似乎不是他們的業務(合法性或ToS合規性是我的責任)的理由拒絕時所做的嘗試。我認爲你應該得到一個公認的答案。 –