我知道在 Stack Overflow 上已经有足够的关于这个问题的内容了，但我的主题与其他人不同（有点相似但不完全相同）。
我想听听社区对我所做的事情的想法，看看是否可以在某些地方进行改进。
目前我正在使用基本授权（BASIC Authorization）作为我的登录 EndPoint，因为它不需要复杂性，并且它是通过 https 进行的，所以它现在的状态很好。
示例：
GET - /api/login
Authorization : Basic BASE64String(username:password)
我的一些 EndPoints 需要 Token 才能获得资源访问权限。这些 Token 我通过 Headers 和 Https-Secured 发送。
问题在于我没有使用传统的授权方法。以下是一些示例：
示例1：
GET - /api/hardware/{PUBLIC_TOKEN}/getMe
Authorization-Hardware : PRIVATE_TOKEN
这个 EndPoint 不需要 Authorization-Hardware Header，但如果包含，API 将执行更多操作。（这里不相关）
示例2：
GET - /api/login/{id}
Authorization-Person : USER_TOKEN
否则需要包含 Authorization-Person Header 和 User Token 才能访问该资源。（注意 Token 的生成方式在这里不重要）
必须使用 HTTPS 请求才能访问 API EndPoints。
我给上面的自定义 Headers 和 EndPoints 随意取了一些名称，只是为了让大家看到我的授权架构，并不代表实际名称。所以请不要关注名称，只需关注架构即可。
我的问题是：不遵循传统方式是否很糟糕？创建自定义授权 Headers 是否有什么问题（如果有，原因是什么）。
我认为这种方式更简单地提供授权和安全地传递 Tokens，所有这些 Tokens 可以在平台上重新生成。
许多设备和移动应用程序已经使用此架构，但都处于开发环境中，还没有进入生产环境。我的担忧是，这种非传统方式可能会影响 API 的用户。希望社区的想法可以帮助我改进。
编辑：2017年3月26日
我想知道，是否最好按照协议中描述的方式来实现，并且为什么。因为当需要多个授权时，按照协议来处理 Authorization Header 比具有自定义 Header 并想要检索其值更困难。
遵循协议，您应该像这样使用 Authorization Header：
Authorization: <type> <value>
示例：
GET - /api/login/{id}
Authorization : User USER_TOKEN
但我无法看到遵循这种方法的好处，因为当获取它的值时，会返回一个字符串，或者在示例中返回用户令牌。
使用自定义标头更容易验证令牌，多个授权可能也会按照协议方式导致麻烦。