REST API總覽 rest-api-overview
Last update: Wed Mar 13 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
此頁面上的內容僅供參考。 使用此API需要Adobe的目前授權。 不允許未經授權的使用。
概觀 over
Adobe Pass Authentication REST API可讓您直接存取TV Everywhere (TVE)驗證和授權服務。 此API支援兩種主要架構：伺服器對伺服器或連線裝置（例如遊戲主機、智慧型電視、機上盒等） 沒有網頁瀏覽功能的應用程式。
節流機制
Adobe Pass驗證REST API由 節流機制.
伺服器對伺服器
伺服器對伺服器解決方案涉及程式設計人員使用者端應用程式，這些應用程式整合了程式設計人員服務，這些服務會與Adobe Pass驗證服務連線，以提供TVE流程。 此方法可將大部分的TVE實作從使用者端轉移至可建置和維護單一統一授權模組的伺服器。 使用者端應用程式的主要剩餘職責是管理使用者驗證的Web檢視。
連結的裝置
連線裝置應用程式會透過REST API直接與Adobe Pass驗證通訊，以執行設定、註冊、驗證狀態檢查和授權流程，而驗證流程需要第二個畫面（瀏覽器）應用程式。 因此，不會使用原生SDK。
其他架構
除了兩種主要的REST API架構之外，還有智慧型裝置的伺服器對伺服器和直接使用者端解決方案，還有其他架構。 其中主要的是SDK架構，此架構使用名為Access Enabler的使用者端元件，由Adobe Pass驗證提供給程式設計師。 應用程式會使用Access Enabler API來處理啟動、驗證、授權和登出。 程式設計師的應用程式與Adobe Pass驗證伺服器之間的所有通訊都會透過Access Enabler進行。 Access Enabler的其他風格可用於下列平台：JavaScript、iOS、tvOS、Android和FireTV。
雖然您可以直接在支援伺服器對伺服器解決方案以外原生SDK的使用者端平台上使用REST API，但不建議使用此方法。
REST API優缺點 ProsAndCons
Adobe Pass Authentication REST API的建立目的，是為沒有網頁瀏覽功能或永久儲存空間的裝置提供隨處電視(TVE)解決方案。 REST API支援所有驗證和授權流程，但缺少原生SDK元件。 由Adobe Pass驗證提供和維護的SDK隨附實作商業規則的現成功能，若是REST API，則必須由程式設計師實作和維護。 在下方的「程式設計師職責」表格中，我們將說明目前需要程式設計師解決的REST API限制。
伺服器對伺服器和使用者端的優點和缺點
伺服器對伺服器架構可將大部分驗證和授權相關邏輯整合為單一邏輯單元或實作。 此方法有利也有弊。 優點包括：
- 驗證和授權商業邏輯的單一實作。
- 避免需在每個支援的平台上使用該平台原生工具實作該邏輯。
- 能夠更新功能，而無須根據使用者端的所有相關需求（例如應用程式商店更新）來更新使用者端。
- 更輕鬆 擴充和自訂authN和authZ功能（例如新增D2C）。
- 直接管理相關流量，以提升控制、品質和監控能力。
同樣地，弊端會列在程式設計師的職責中，但包括下列各項：
- 必須針對每個使用者端實作SSO，才能使用未安裝Platform SSO的平台。
- 如有必要，程式設計師必須實作MVPD特定邏輯。
- 所有使用REST API的平台都共用單一設定來管理屬性，例如驗證TTL。
連結的裝置
對於大部分的連線裝置，由於SDK無法使用，因此REST API必須以某種方式使用。 連線的裝置將直接使用REST API，或整合使用REST API的伺服器對伺服器解決方案。
程式設計師職責 programmer-responsibilities
下列專案適用於伺服器對伺服器和連線裝置應用程式。
功能
負責處理功能
說明目前無使用者端API的限制以及與原生SDK的差異
每個平台套用的組態設定
Adobe
一
主要限制 在所有平台(包括iOS和Android等行動裝置)上使用REST API時，我們TVE儀表板設定工具中與REST API對應的設定設定會套用至所有裝置(即使有iOS裝置執行在REST API上實作的原生應用程式)。 此限制
可以中斷 與MVPD間的TTL協定與平台設定協定 — 如果這些協定與每個平台不同。
1
單一登入
程式設計師
使用REST API時，SSO僅適用於支援Platform SSO的平台(例如Apple、Roku、Amazon)，而使用REST API時，其他平台無法保證SSO。 SDK會以跨網站/應用程式的方式快取資料。 這表示使用者在網站/應用程式上登入一次，且已登入參與的網站，無需任何使用者互動。
2
單一登出
程式設計師
在本機SDK SSO案例中，從某個參與應用程式登出後，使用者將會從任何地方登出。 在目前不支援SLO的REST API上，從某個應用程式登出只會為該特定應用程式登出使用者。
快取
程式設計師
REST API實作必須針對業務認可的資料專案實作自己的快取機制。 SDK會自動快取各種資料專案，同時考慮到各種商業規則。 例如，使用者中繼資料會使用與驗證Token相同的TTL來快取，而某些專案可以程式設計方式從快取（預檢）中排除。
詳細的錯誤報告機制
程式設計師
REST API主要仰賴HTTP錯誤碼來報告應用程式錯誤，而SDK具有詳細的錯誤報告機制，可協助應用程式開發人員更能瞭解正在發生的事情。
應用程式錯誤復原（錯誤時重試、回圈偵測等）
程式設計師
REST API實作需要建立自己的應用程式復原系統，而透過SDK進行的實作則受益於SDK錯誤復原系統：透過重試特定具有就地邏輯的網路呼叫來防止「回圈」，從暫時性的網路錯誤中復原。
每個要求者的驗證
程式設計師
有些MVPD基於業務原因或技術挑戰，需要針對每個網站/應用程式進行驗證。 SDK會根據TVE儀表板設定自動強制執行此功能。 REST API實作人員必須自行實作此作業，以免違反商業合約，或完成授權給那些根據應用程式來限定其驗證資料的MVPD。
被動驗證
程式設計師
有些MVPD支援「被動」驗證，使用者不需要輸入認證，而且會嘗試自動驗證使用者。 這對於也具有「每個要求者的驗證」要求的MVPD特別有用。 在這種情況下，SDK啟用的UX會是無縫的，使用者只需在應用程式中驗證一次，而SDK會針對生態系統內的其他應用程式執行「被動」驗證。 使用者看不到其他被動呼叫，只是會先通過驗證，而MVPD則會達成每個應用程式擁有個別驗證工作階段的目標。
隱含和統一的裝置偵測
程式設計師
SDK會自動偵測裝置型別，並以標準方式傳送該資訊。 REST API實施會根據實作者而易於傳送不同資訊，因此會扭曲/破壞網站間的商業規則和統計資料。 程式設計師必須確定他們傳送正確的裝置資訊給我們 每個應用程式上的。 針對伺服器對伺服器實作，除非採取其他步驟，否則REST API無法正確識別一般使用者的IP位址。 IP位址在某些使用案例中很重要，例如防止詐騙或HBA。
竄改證明TempPass
程式設計師
強制執行TempPass是以穩定的裝置ID為基礎。 SDK會使用硬體資訊/指紋技術來識別裝置，而且此機制不是公開的，因此會更安全且不會發生衝突。 針對REST API實作，程式設計師需要實作自己的裝置識別/指紋識別演演算法。
裝置繫結
程式設計師
在透過SDK使用應用程式的裝置上產生的權杖無法攜帶，使得惡意使用者難以共用其權杖並提供存取權給其他使用者。 這是根據與「防竄改TempPass」相同的裝置ID機制。 針對REST API，Token會保留在雲端，這表示具有相同deviceID且進行相同呼叫的兩個裝置將獲得相同的回應/存取權。 程式設計師必須確定他們對於產生/分配裝置ID有健全、安全且無衝突的機制。
可預測且經過認證的功能組合
程式設計師
每個SDK中的現有功能集都是一致的、可預測，並已通過完整認證和測試。 有些業務需求會透過SDK強制執行，使得程式設計師在使用REST API時違反合約的風險增加。 雖然REST API可能更具彈性，但Adobe可確保SDK實作可強制執行TVE Dashboard的業務決策和設定。 在無使用者端的情況下，每個程式設計師會實作其專屬的商業規則子集，這些商業規則會在指定時間點套用其應用程式。
-
在我們新的One API計畫中，我們計畫修正此限制，並能夠根據裝置識別為每個平台套用規則。
-
Adobe會持續與所有主要平台合作，以實作可與我們的REST API搭配使用的Platform SSO。 我們的One API計畫將在使用原生SDK實作的應用程式與使用REST API實作的應用程式之間提供SSO支援。
最低裝置需求 min_reqs
為了使用Adobe Pass驗證REST API，裝置必須符合或超過 Adobe Pass驗證平台/裝置/工具需求檔案.