安全地，我想
2020年3月31日，大家最喜欢的iPhone天气应用程序宣布他们已经加入了苹果。不久之后，他们优秀的API不再接受新的注册，并定于三年后的2023年3月31日完全关闭。嗯，时间过得真快，我们现在离这个日期不到一年了。我不禁回忆起我最喜欢的两个由黑暗天空驱动的项目。紫雨报告和Tycho的预测播放列表生成器。他们简单而强大的API总是那么鼓舞人心，我个人也喜欢天气。那么，我们现在该怎么做呢？好吧，看起来Dark Sky团队已经在他们的新家苹果公司努力工作，为我们带来了WeatherKit，一个全新的苹果天气服务，提供我们所依赖的同样的数据：超本地天气信息，10天的小时预报，每分钟的降水量，以及更多。最令人惊讶的是什么？除了典型的平台专用API外，它还有一个REST API。最不令人惊讶的是什么？要生成一个网络令牌来进行调用，这很复杂。
是的，我想起了苹果MusicKit JS的推出，他们推出了一个令人兴奋的新服务，但没有提供关于正确生成调用它所需的令牌的文档，让许多兴奋的开发者感到困惑和沮丧。事实证明，我在这里读得最多的一篇博客就是关于创建苹果音乐API令牌的简化说明。😅 在WeatherKit的辩护中，他们确实在推出一周后发布了一些认证说明。因此，如果你遵循这些说明，你应该能够让苹果WeatherKit REST API启动和运行。
与苹果音乐API令牌不同的是，这里看起来并不是一个长期存在的令牌就够了，相反，你要在两次调用之间保持该令牌的新鲜度。这意味着你要在用户每次发出天气请求时生成令牌。实际上，当WeatherKit REST API发布时，我正在Netlify上构建一个由Dark Sky API驱动的客户端项目，并做出了一个有疑问的决定，即尝试整合测试版API。风险很大，我知道。所以，我知道如何使用JSON网络令牌包，按照苹果的指示生成一个有效的网络令牌，但为了通过Netlify功能分发这个解决方案，我需要弄清楚如何处理我的私钥。一个新的令牌必须由私钥（由苹果提供的.p8文件）签署，但私钥不应该被分发，所以我不想把它放在我的Github仓库里。我到底要怎么处理这个问题呢？
环境变量？
嗯，这就是我所做的。事实上，我最后把我的私钥编码成一个Base64字符串，这样我就可以把它作为一个环境变量储存在Netlify管理中。然后我在我的Netlify函数上对它进行解码，用它来签署我的JWT令牌。最后，它看起来很像我的苹果音乐API令牌生成逻辑，尽管有推荐的头文件和有效载荷。所 这个编码后的密钥被存储为一个环境变量，与这个苹果WeatherKit项目相关的团队、密钥和应用程序ID一起。
下面是我用来生成新令牌的 Netlify 函数，最后用axios 调用 WeatherKit REST API。首先，我把 Base64 私钥解码成原始格式。然后，我从环境变量中抓取我的团队、密钥和应用程序ID。所有这些元素都被用来生成一个JWT令牌，该令牌在1小时后失效。Netlify函数本身有纬度和经度的查询参数，这些参数与头中的JWT令牌一起传递给axios API调用。如果一切顺利，天气数据将由Netlify函数端点返回。
这比黑暗天空的API好吗？我还不确定。然而，我确信它的访问方式比在一键式接收一个不到期的API令牌要混乱得多。(旧的黑暗天空API流程。)我希望像这样的文档能够缓解围绕这个新API的一些困惑，这样我们就可以弄清楚这对我们的网络应用来说是否是一个可行的解决方案，或者我们是否应该继续寻找其他的解决方案，比如Open Weather。如果你认为我在这里做的事情是聪明的或愚蠢的，请告诉我。我很感谢任何关于将这个API安全地整合到未来项目中的提示。
