久草在线视频资源,国产99精品在线观看,最近中文在线mv视频在线

需要注意的是，配置應用內購買和 Game Center 還是需要通過App Store Connect 網站進行配置。

現有的解決方案

Fastlane 已經是一個完善的自動化工具，它提供了如 produce 等工具用于更新元數據。為啥還要關心 App Store Connect API 呢？

首先 App Store Connect API 是蘋果官方提供的，適用于所有環境。Fastlane 基于 ruby 的，限制適用的技術棧。

其次 Fastlane 是通過 Spaceship 來訪問 Apple Developer Center 和 App Store Connect 的。目前 Spaceship 是通過解析網頁來實現自動處理的，會有以下幾個問題：

Apple Developer Center 和 App Store Connect 是兩個不同的網站，因此需要兩次認證，存兩份cookie。
現在 Apple ID 強制開啟了雙重認證，每次登錄需要驗證碼，無法完全自動化。cookie 也只能保持 1 個月。
Apple Developer Center 和 App Store Connect 如果有頁面更新，Spaceship 就需要升級來適應變化。

如果都能夠用 App Store Connect API 來實現，則這些問題就不存在了。

App Store Connect API 也有一些不完善的地方，例如其 token 有效期只有 20 分鐘，固然增強了安全性，但是如何簽名產生這個 token，還需要總結出一個最佳實踐。

瑕不掩瑜，業界對 App Store Connect API 還是蠻期待的。Fastlane 在 2.150.0 的分支中已經添加對新的 App Store Connect API 的支持。相關討論 issue：Fastlane: Support new App Store Connect APIs^[1]

App Store Connect API 的新內容

文檔

這次新增了 200+ 的 RESTful endpoint，和原來相比翻了一倍。蘋果爸爸還將提供一個 openAPI 規范文件供您下載（OpenAPI Specification^[2]?是流行的swagger格式的開放標準第三版）。可以在 swagger UI 中查看它，以獲取快速的 API 參考。或者更好的方法是將其輸入代碼生成器中，以更快，更輕松地引導幾乎所有語言的 API 集成。蘋果爸爸還聲稱會添加了一些有關速率限制和文件上傳等主題的新說明文章，提供可下載的示例代碼，以演示重要的 API 概念，例如創建和簽名身份驗證令牌，與API響應進行交互以及使用新的資產上傳 API。

。詳情可以參考：App Store Connect API Resources^[3]

應用元數據API （app metadata API）

Session?Expanding automation with the App Store Connect API^[4]?中 Geoff Coffey 是通過一個例子，貫穿講解了相關的 API，包括以下?5 個步驟：創建一個新版本，設置定價以更新應用程序元數據，將構建與該版本相關聯，然后將該新版本提交給App Review 。本文就做一個簡要的總結，不再一一列舉了。

新API遵守原有的 App Store Connect API 的認證方式。可以參考文章?App Store Connect的新特性(WWDC 2018 session 301 & 303)^[5]，?App Store Connect API^[6]

基本規則

應用元數據的相關資源以及它們的關系如下圖所示。

圖中每個節點代表 restful api 中的一個資源，例如 /v1/apps。圖中聯線代表資源之間的關聯，例如：一個 App 可以有多個 App Store Versions。每個資源的數據結構如下

data: {

    "type": 資源名,

    "id": 資源ID，

    "attributes": {

        資源自己的屬性

    },

    relationship: {

        "關聯資源名": {

            "data" : { "type": 資源名, "id": 資源ID }

        }

    }

}

查詢資源

通過 GET 方法請求資源路徑就可以獲得對應資源的元數據。

可以通過添加形如 filter[key]=value 的 query string 來過濾返回的結果。例如：

GET /v1/apps?filter[bundleID]=org.forestexplorer.ForestExplorer

GET /v1/builds?filter[app]=appid&filter[perReleaseVersion.version]=1.1&fileter[version]=3

此時返回結果 data 是一個數組。

可以通過指定資源的 ID，來確定的獲得一個資源的數據。例如：

GET /v1/apps/資源ID

此時返回結果 data 是一個對象。

當然也可以獲取一個確定資源的關聯資源。例如：

GET /v1/appStoreVersions/資源ID/appStoreVersionLocalizations

GET /v1/appStoreVersionLocalizations/資源ID/appPreviewSets

可以通過添加include=關聯資源名的 query string 來讓返回結果同時包含關聯資源，例如：

GET /v1/apps/資源ID/prices?include=priceTier

修改資源

修改資源通過 http 的 patch 方法。路徑需要指定對應的資源 ID。有意思的是，如果想要用一個原子操作，修改資源的同時為資源添加關聯資源。而此時由于新添加的資源還沒有創建，沒有一個正式的資源 ID。可以通過 ${臨時資源ID} 的方式由創建者臨時指定一個資源 ID，并在 data 的同級添加一個 included 其中包含臨時資源 id。只要臨時資源 ID 相同，就會關聯并創建。在返回結果中會更正為真正的資源 ID。例如

PATCH /v1/apps/資源ID/

{

    "data": {

        "type": "apps",

        "id": 資源ID,

        "relationships": {

            "prices": {

                "data" : [{ "type": "appPrices", "id": "${tmpid}" }]

            }

        }

    },

    "included": [{

        "type": "appPrices",

        "id": "${tmpid}",

        "attributes": {

        },

        "relationships": {

            "priceTier": {

                "data": { "type": "priceTiers", "id": "0" }

            }

        }

}

當然也可以直接修改一個資源的關聯資源，例如修改一個appStoreVersion 關聯的build

PATCH /v1/appStoreVersions/資源ID/relationships/build

創建資源

一個典型的例子是在 AppStore 添加一個新的版本：

POST /v1/appStoreVersions



{

    "data": {

        "type": "appStoreVersions",

        "attributes": {

            "platform": "IOS",

            "versionString": "1.1"

        },

        "relationships": {

            "app": {

                "data": {"type" : "apps", "id" : "資源ID" }

            }

        }

    }

}

創建新資源不用添加”id”屬性，創建成功后，ID會自動生成，并在結果中返回

appPreviews 和 appScreenshots 不僅僅包含元數據，還包含具體的圖片、視頻文件，這些怎么上傳呢？圖片、視頻文件被統一叫做 asset，代表大數據文件。在創建 appPreviews 和 appScreenshots 的元數據成功后，服務端會返回一個屬性字段 "uploadOperations" 其中包含了上傳 asset 的相關信息。例如 url、method、offset、length，以及請求的headers。使用者還需要通過這些信息上傳asset。

需要注意的是，?"uploadOperations"?可能返回一個數組，這樣可以將大文件分段上傳。上傳的順序可以打亂，也可以并發上傳，其中一塊失敗了只需要重傳失敗的塊就行了。

當所有塊都上傳成功后，還需要更新一下 appPreviews 元數據的狀態。標記 uploaded 為 true 并且附上 sourceFileChecksum。app store connect 會對上傳的asset再做處理。這個處理是異步的。需要通過查詢 appPreview 的元數據來確認處理狀態。

診斷數據API （Power and Performance Metrics and Diagnostics API）

診斷數據API獲取的數據是顯示在Xcode中的功能和性能視圖（上圖）中的數據。有另外一個session:?Identify trends with the Power and Performance API^[7]?詳細講解其中的具體數據內容。

診斷數據可以通過 app 或者 build 維度獲取，具體路徑形如：

GET /v1/apps/資源ID/perfPowerMetrics

GET /v1/builds/資源ID/perfPowerMetrics

這里由于返回的數據是蘋果定制的格式，因此需要在請求頭中添加accept類型如下：

accept: application/vnd.apple.xcode-metrics+json

特別指出，在磁盤寫入時，會包含一些堆棧信息，因此還有一個diagnosticSignature的資源節點以及關聯的logs資源節點

GET /v1/builds/資源ID/diagnosticSignatures

GET /v1/diagnosticSignatures/資源ID/logs

總結

新的 app metadata API 提供了一種官方支持的自動化發布app的方案。大家可以開動想象力，發揮它的潛力。例如，通過這些 API 一些面向企業的 APP 都可以高效的自動生成定制化版本。再結合蘋果正在推廣的 Apple Business Manager ，定向為企業發布定制化版本的app。或者未來會涌現出一些簡化開發的平臺，提供模板和上線服務。只要你有創意和資源，就可以一鍵在AppStore 上發布一個應用了。

本文章轉載微信公眾號@老司機技術