各公司 API 接口设计观察

测试过程

因为我的两个帖子 /t/838609 /t/846741 V 友们的意见都不太统一，刚好看到今天有人又在争论这个问题，于是我打算看看各公司 API 的接口设计

YouTube

首页随便找了个接口:

POST https://www.youtube.com/youtubei/v1/att/get?key=<input>&prettyPrint=true

Request:

key=?
prettyPrint=?

Success Case (HTTP 200):

{
  "responseContext": {
    "serviceTrackingParams": [
      {
        "service": "**",
        "params": [
          {
            "key": "**",
            "value": "WEB"
          },
          {
            "key": "**",
            "value": "**"
          },
        ]
      },
      **
    ],
    "mainAppWebResponseContext": {
      "datasyncId": "**",
      "loggedOut": false
    },
    "webResponseContextExtensionData": {
      "hasDecorated": true
    }
  },
  "challenge": "**",
  "botguardData": {
    "program": "**",
    "interpreterSafeUrl": {
      "privateDoNotAccessOrElseTrustedResourceUrlWrappedValue": "//www.google.com/js/**.js"
    }
  }
}

Fail Case （不传 Key 字段 HTTP 403 ）：

{
  "error": {
    "code": 403,
    "message": "The request is missing a valid API key.",
    "errors": [
      {
        "message": "The request is missing a valid API key.",
        "domain": "global",
        "reason": "forbidden"
      }
    ],
    "status": "PERMISSION_DENIED"
  }
}

Fail Case 2 （ Key 随便传了个 0 HTTP 400 ）：

{
  "error": {
    "code": 400,
    "message": "API key not valid. Please pass a valid API key.",
    "errors": [
      {
        "message": "API key not valid. Please pass a valid API key.",
        "domain": "global",
        "reason": "badRequest"
      }
    ],
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "API_KEY_INVALID",
        "domain": "googleapis.com",
        "metadata": {
          "service": "**.googleapis.com"
        }
      }
    ]
  }
}

Gmail

大部分 API 都有混淆，选一个列登录 Google 账号列表的

POST https://accounts.google.com/ListAccounts

Requests:

listPages=?
authuser=?
pid=?

Success Case (HTTP 200):

["**",[["**",1,"**","**@gmail.com","https://**.googleusercontent.com/**.jpg",0,0,1,null,1,"**",null,**]]]

Success Case 2 (清空 Cookies 后测试 HTTP 200):

返回长度 0 的内容。

Fail Case (listPages 传负数 HTTP 400 ）：

返回长度 0 的内容。

另外这里看到了 3 个 ASP.NET Core 官方模板风格的请求（路由大驼峰，参数小驼峰）

Twitter:

推特详情 API ，懒得截图了

GET https://twitter.com/i/api/graphql/**/TweetDetail

Request:

variables=%7B%22focalTweetId%**

URL 解码后：

{"focalTweetId":"**","referrer":"home",**

Success Case (HTTP 200):

{
    "data": {
        "threaded_conversation_with_injections_v2": {
            "instructions": [
                {
                    "type": "TimelineAddEntries",
                    "entries": [
                        {
                            "entryId": "**"
                            **

Fail Case (随便破坏 JSON 结构几个字符 HTTP 400 ）

{"errors":[{"message":"Cannot parse variables: \"focalTweetId\\\"**

Fail Case 2 （传不存在的推特 ID HTTP 200 ）

{"errors":[{"message":"_Missing: No status found with that ID.","locations":[{"line":5,"column":3}],

后续我又测试了 Amazon ，Azure ，AT&T 的 API ，结果都属于上面几种情况，因为过滤并检查是否有隐私信息麻烦就不贴了。

各公司 API 接口设计观察

测试过程

结论