Partkeepr: 八分之一题

所以我们可以理解您的建议 - 如何衡量每月 500 个零件的请求？ 我们不托管任何东西，所以每个人都在运行自己的服务器。

嗨布雷特，

当从查询返回部件时，部件请求被计算在内。 每个用户
必须在 Octopart.com 上申请自己的 API 密钥，因此限制
将是每个用户的基础。

您是否觉得这足以为 PartKeepr 带来价值？
最喜欢的用户？ 说实话，除了Demo实例我没用过
PartKeeper。

任何见解将不胜感激！

2020 年 5 月 21 日星期四晚上 9:14，bret watson [email protected]
写道：

所以我们可以理解您的建议 - 500 部分如何
请求/月测量？ 我们不托管任何东西，所以每个人都在跑步
他们自己的服务器。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-632424718 ，
或退订
https://github.com/notifications/unsubscribe-auth/APVO4KPUSHS7MXHRTHQLA23RSXGWDANCNFSM4NHL37GQ
.

原谅我的无知，因为我不使用 Octopart.. 但请求 - 是股票查询、产品搜索还是订单？

@baradhili长话短说：它们浓缩了有关零件的各种信息，以便用户可以下载这些信息，如卖家数据、数据表、设备参数等。将零件快速导入 PartKeepr 非常好。
如果您一次导入十几个零件，这是非常有价值的。

@JamesOctopart我可以告诉你我的个人想法。 这不是 PartKeepr 的官方声明。
我的路线与https://github.com/partkeepr/PartKeepr/issues/1030#issuecomment -632406313中的@aarontc 类似。 当您开始将新零件导入数据库时​​，您每天可以快速导入多个零件。 清点地下室时，您可以在一个周末轻松进入 1000 年代。 另一方面，这不是我每天都会做的事情。 所以也许只有更长的时间范围和大量的请求就足够了（不是 500 个零件/月，而是 1500 个零件/3 个月）。
对于那些需要进口更多零件的人，应该可以通过一次性支付来提高水平。 像我购买了 2000 次额外访问，这些访问在我的每月预算为空后使用。

还有一点需要注意：我说的是导入部件的数量，而不是 API 访问时间。 如果零件在数据库中，则进行一次搜索，然后选择导入的所有相关部分和所有下载，从而创建大量 API 访问。 如果您正在考虑 500 次这样的访问，那么这很可能太低了。 但我没有在这里查看 API 的详细信息。

我会对此非常感兴趣，因为我依靠 Octopart 来推动我的 KiCad2PartKeepr 项目。

https://github.com/Gasman2014/KC2PK

对于我的个人项目，500 个零件的级别会很有趣。 API 变化很大吗？ 确保应用程序与 API 良好配合需要测试，因此欢迎开源开发人员在不购买订阅的情况下获得一些灵活性。

在你的服务器上通过 api 键收集一些统计信息怎么样？ 也许给那些要求他们作为业余爱好者的人一些钥匙然后计算他们的平均使用量是个好主意。

我怀疑你会找到一个合理的用户平均值来计算所需的 API 调用，但至少这是一种方法。

当我在考虑我的 PartKeepr 设置时，我会发现如果一个爱好者获得一个月的无限制测试，然后每个月有几百个请求是合理的。 在我的情况下，我将在初始设置库存时使用一些 thound 调用，但后来添加的部件并不多。

我很想获得 OctoPart 的免费零件/月配额。 获取零件数据非常方便。
是的，最初您可能需要超过 500 个，但是插入 500 个组件仍然是相当多的工作（好吧，这不需要一个月）。

所以，是的，请！

我相信这只是一个宣传噱头。 我已经发送了各种电子邮件，询问将来是否有可能获得免费的 api 访问权限，但根本没有收到任何答复。

Ola PTDreamer，你就是 stm32 烙铁头！ 仍然没有完成我的 JBC 铁杆。

我向 SnapEDA 提出了类似的问题，他们在 2 个月后（上周）回复了我。 让我们希望他们对我们更加宽容。

我在下一个工作日收到 Octopart 的回复，确认他们计划“在几周内”提供免费套餐。 这是在六月初。 手指仍然交叉！

2020 年 7 月 2 日 13:35，Martijn Kuipers [email protected]写道：

Ola PTDreamer，你就是 stm32 烙铁头！ 仍然没有完成我的 JBC 铁杆。

我向 SnapEDA 提出了类似的问题，他们在 2 个月后（上周）回复了我。 让我们希望他们对我们更加宽容。

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-652979341 ，或取消订阅https://github.com/notifications/unsubscribe-auth/ACADFOKBXDWBKPB2CL3U273RZR5I3ANCNFSM4NHL37GQ 。

IDK，我几周前给他们发了电子邮件。 他们表现得好像他们从未听说过 Partkeepr.... 也许他们就是这样找到这个项目的？

我的查询并不是专门关于 PartKeepr 的——我也曾经使用 Octopart 来处理我的 BOM 订购应用程序——它使用 PartKeepr 数据库作为后端。 (Kicad2Partkeepr) 但由于他们删除了 API 访问权限，因此无法使用它。

https://github.com/Gasman2014/KC2PK https://github.com/Gasman2014/KC2PK

2020 年 7 月 2 日 16:23，Michael Fisher [email protected]写道：

IDK，我几周前给他们发了电子邮件。 他们表现得好像他们从未听说过 Partkeepr.... 也许他们就是这样找到这个项目的？

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-653071390 ，或取消订阅https://github.com/notifications/unsubscribe-auth/ACADFOOBDRUB3YDZBCRQYCTRZSQ6LANCNFSM4NHL37GQ 。

首先，我不得不说我没有对 PK 使用的关于 Octopart 的协议进行逆向工程。 所以这里的每一个陈述都只是我有根据的猜测。

请注意 API 请求编号。 我不确定，对于一个零件的单次搜索，有多少请求 PK 开始了。 可能每次下载（数据表、图像等）都是唯一的 API 调用。 对于分销商的数据等也是如此。
这将导致单个搜索花费至少 10 个 API 请求！ 这意味着在 50 个零件/月后您达到了限制。

是否有人愿意检查这一点，这将对我们所有人都有帮助。 不幸的是，我现在没有时间完成我的工作。

顺便说一句：我也在 Octopart 询问过。 他们告诉我以下内容：

当前的 API 目前不提供免费访问。 我理解您的担忧，对于给您带来的不便，我深表歉意。 然而，我很高兴地提到，Octopart 正在推出一个新版本，它将拥有免费层的基础设施，希望在今年夏天结束。

我们希望在 API v4 发布时看到您注册。 请让我知道，如果你有任何问题。

我想强调的是，由于缺乏开发能力，我们可能无法使用所提到的 Octopart API v4。

今年年初，我的 Octopart 注册被拒绝，因为我的用例（Partkeeper 作为爱好者）与 Octopart 的使用条款不兼容。
这些条款特别提到您不能在自己的系统上下载和存储数据（如数据表），并且从 Octopart 检索到的所有数据最多只能缓存 24 小时。 (https://octopart.com/api/terms)
这意味着您将不得不一直使用 API，并且有一个硬性限制，我不希望我的项目在达到 API 调用限制时停止。

总的来说，对于 PartKeepr，我更感兴趣的是能够集成 Octopart 之外的其他 API。
大多数零件分销商向其客户提供 API，以检索数据表和定价信息。
它不是单一的聚合数据源，但这意味着它也不是单点故障或瓶颈。

大家好，

在我们推出新的 GraphQL API 时更新此线程
非常兴奋，可以在这里找到： https ://octopart.com/api

一些更新：

我们的免费套餐允许每月退回 500 个零件，并且能够
如果需要，购买更多。

需要做一些工作来确保 PK 可以查询我们的新
API，我们的入门指南可以在这里找到：
https://octopart.com/api/v4/getting-started。

如果担心免费层的部分限制，我建议使用
限制为 1 的 multi_match 以确保每个匹配只返回一个部分。

我们希望我们 API 中的新功能对 PK 社区有价值，
如果您有任何问题，请告诉我，您可以直接给我发电子邮件
[email protected]

-詹姆士

2020 年 7 月 2 日星期四下午 12:04 Christian [email protected]写道：

首先，我不得不说我没有对PK的协议进行逆向工程
关于 Octopart 的用途。 所以这里的每一个陈述都只是我有根据的猜测。

请注意 API 请求编号。 我不确定，有多少请求 PK
正在开始对零件进行一次搜索。 情况可能是每个
download (datasheet, image, ...) 是一个独特的 API 调用。 同样的道理
用于分销商的数据等。
这将导致单个搜索花费至少 10 个 API 请求！ 那
表示在 50 个零件/月后您达到了限制。

是否有人愿意检查这一点，这将对我们所有人都有帮助。 很遗憾，

我现在没有时间完成我的工作。

顺便说一句：我也在 Octopart 询问过。 他们告诉我以下内容：

当前的 API 目前不提供免费访问。 我明白
您的担忧，对于给您带来的不便，我深表歉意。 不过，我很高兴
提到 Octopart 正在推出一个新版本，该版本将具有
免费层的基础设施，希望在今年夏天结束。

我们希望在 API v4 发布时看到您注册。 请让我知道是否
你有任何问题。

我想强调的是，由于缺乏开发能力，我们可能不会
能够使用 Octopart 的上述 API v4。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-653094570 ，
或退订
https://github.com/notifications/unsubscribe-auth/APVO4KJABPVCMTJQSICYJXTRZSVYRANCNFSM4NHL37GQ
.