我想寫一個應用程序，將與Last.fm API交互，我被卡住了。 我的問題與授權有關。從Last.fm API網站報價：通過瀏覽器授權
您的應用程序需要打開一個網頁瀏覽器的一個實例，併發送 用戶與你的API密鑰和認證令牌 作爲參數傳遞給last.fm/api/auth。使用HTTP GET請求。
我知道如何發送GET請求以及如何使用指定的URL打開瀏覽器。但是，當用戶批准或拒絕瀏覽器中的授權時，如何實現此功能並捕獲我的應用事件？也許我應該使用HTTP GET 15秒，如果我沒有收到用戶名，我應該讓用戶再次執行授權。這是一個正確的方式嗎？
這是有點意思。這些說明使其看起來很簡單，但這實際上是一個難題，甚至沒有出現Last.fm自己的liblastfm C++ library與服務交互提供解決方案。
在難度不斷增加的順序一些方法包括：
打開默認的Web瀏覽器的URL，併爲用戶顯示一個按鈕，他或她已授權應用程序後點擊。
優點：簡單
缺點：用戶體驗較差。您需要確保用戶有明確的說明才能遵守，以免他/她感到困惑。另外，用戶可能會認爲你的應用已被破壞，因爲「他們已經授權你的應用！」，並沒有意識到你的應用直到他或她按下按鈕纔會知道。
打開默認的Web瀏覽器到URL，顯示無限期的「等待來自Last.fm的授權」消息，並每隔15秒鐘輪詢auth.getSession方法API調用以查看用戶是否授權您的應用程序。也許還提供了「現在檢查」按鈕。
優點：簡單而不會像用戶體驗那麼差。
缺點：API似乎沒有提供用戶拒絕授權的錯誤代碼。您可能不知道用戶是否授權您的應用程序，並且您可能會永久等待授權。另外，我不知道auth.getSession調用是否有限制，但是您可能會面臨速率限制問題。
將Web瀏覽器嵌入到您的應用程序中。你可以完全控制它，設置事件處理程序應該很簡單。
優點：無需輪詢，因爲應用程序在用戶提交表單時收到通知。
缺點：用戶界面可能會讓某些用戶感到困惑。
向操作系統註冊自定義URI方案，並使用Last.fm的instructions for authorizing web applications。
這個想法是註冊URI方案（也稱爲應用協議;例如myApp://），並使用自定義方案（例如myApp://lastFmAuthorizationCallback）指定回調URL。
參見：
（特定平臺）自動化的Web瀏覽器。確切的做法取決於網絡瀏覽器和平臺。
優點：可以無縫連接。應該在正確完成時提供出色的用戶體驗。
缺點：棘手的開發和自動化可能會破壞瀏覽器的升級。
它部分取決於您用來啓動瀏覽器進程的API。如果您正在使用可在啓動的進程退出時檢測到的API，請使用該機制。 HTTP GET的/ auth調用不會收到任何類型的用戶名。按照authentication documentation for desktop apps的其餘部分，瀏覽器會自動關閉，當用戶已經批准：
一旦用戶授權使用他們的 帳戶您的應用程序的許可，基於瀏覽器的過程已經結束，用戶問到 關閉他們的瀏覽器並返回到您的應用程序
在此之後，還有一些步驟讓您經歷。您接下來需要撥打auth.getSession以獲得會話。如果用戶尚未批准您的應用，此通話將失敗（並且您可以向用戶展示他們需要批准您的應用並再次向他們提供鏈接的失敗）。以下是各類可能發生的錯誤列出：
錯誤
4：無效的認證令牌提供
14：此令牌沒有被授權
15：此標記已過期
4：身份驗證失敗 - 您無權訪問服務
9：無效的會話密鑰 - 請重新認證10：無效的API密鑰 - 您必須被授予
等等
您在會議上批准後，就可以開始進行適當的調用
是涉及瀏覽器，還是純粹使用C++代碼發送HTTP請求？ –
涉及瀏覽器。 – DuXeN0N