Partkeepr: Question Octoparts

Nous pouvons donc comprendre ce que vous proposez - comment la demande de 500 pièces/mois est-elle mesurée ? Nous n'hébergeons rien, donc chaque personne gère son propre serveur.

Salut Bret,

Les demandes de pièces sont comptées lorsqu'une pièce est renvoyée à partir d'une requête. Chaque utilisateur
devraient demander leur propre clé API sur Octopart.com afin que les limites
serait une base par utilisateur.

Pensez-vous que cela suffirait à apporter de la valeur à PartKeepr
les utilisateurs les plus amateurs ? Pour être honnête, à part l'instance de démonstration, je n'ai pas utilisé
PartKeepr.

Toute idée serait grandement apprécié!

Le jeu. 21 mai 2020 à 21 h 14 bret watson [email protected]
a écrit:

Nous pouvons donc comprendre ce que vous proposez - comment est la partie 500
demande/mois mesuré ? Nous n'hébergeons rien donc chaque personne court
leur propre serveur.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-632424718 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/APVO4KPUSHS7MXHRTHQLA23RSXGWDANCNFSM4NHL37GQ
.

Pardonnez mon ignorance car je n'utilise pas Octopart.. mais la demande - est-ce une requête de stock, une recherche de produit ou une commande ?

@baradhili Pour faire court : ils condensent diverses informations sur les pièces afin que les utilisateurs puissent télécharger ces informations telles que les données du vendeur, les fiches techniques, les paramètres de l'appareil, etc. Très agréable d'importer rapidement des pièces dans PartKeepr.
C'est très utile si vous importez plus d'une douzaine de pièces à la fois.

@JamesOctopart Je peux vous faire part de mes réflexions personnelles à ce sujet. Ceci n'est pas une déclaration officielle de PartKeepr.
Je suis sur un itinéraire similaire à @aarontc dans https://github.com/partkeepr/PartKeepr/issues/1030#issuecomment -632406313. Lorsque vous commencez à importer de nouvelles pièces dans la base de données, vous en importez rapidement plusieurs par jour. Vous pouvez facilement atteindre les milliers en un week-end lorsque vous faites l'inventaire de votre sous-sol. D'un autre côté, ce n'est pas quelque chose que je fais au quotidien. Alors peut-être qu'un horizon plus long avec une multitude de demandes pourrait suffire (pas 500 pièces/mois mais 1500 pièces/3mois).
Pour ceux qui ont besoin d'importer plus de pièces, il devrait être possible d'augmenter le niveau en payant en une seule fois. Quelque chose comme j'achète 2000 accès supplémentaires qui sont utilisés après que mon budget mensuel est vide.

Une note de plus : je parle du nombre de pièces importées, pas des temps d'accès à l'API. Une seule recherche si une pièce est dans la base de données, puis la sélection de toutes les pièces pertinentes de l'import et de tous les téléchargements créent une multitude d'accès API. Si vous envisagez 500 de ces accès, c'est probablement trop peu. Mais je n'ai pas examiné les détails de l'API ici.

Cela m'intéresserait beaucoup car je me suis appuyé sur Octopart pour piloter mon projet KiCad2PartKeepr.

https://github.com/Gasman2014/KC2PK

Pour mes projets personnels un niveau de 500 pièces serait intéressant. L'API a-t-elle beaucoup changé ? S'assurer qu'une application fonctionne bien avec une API nécessite des tests et donc une certaine flexibilité pour les développeurs open-source sans acheter d'abonnement serait la bienvenue.

Qu'en est-il de la collecte de statistiques par clé API sur votre serveur ? C'est peut-être une bonne idée de donner quelques clés aux personnes qui les demandent en tant qu'amateurs, puis de compter leur utilisation moyenne.

Je doute que vous trouviez une moyenne raisonnable d'utilisateurs pour calculer les appels d'API requis, mais au moins c'est une voie à suivre.

Alors que je réfléchissais à ma configuration de PartKeepr, je trouverais raisonnable qu'un amateur obtienne un mois de test illimité et plus tard quelques centaines de demandes par mois. Dans mon cas, j'utiliserai quelques milliers d'appels dans la configuration initiale de l'inventaire, mais plus tard, il n'y a pas beaucoup de pièces ajoutées.

J'aimerais obtenir le quota pièces/mois gratuit pour OctoPart. Il est si pratique d'obtenir les données de vos pièces.
Oui, au départ, vous avez probablement besoin de plus que les 500, mais l'insertion de 500 composants est encore un travail à faire (ok, cela ne prend pas un mois).

Alors, oui s'il vous plait !

Je crois que ce n'est qu'un coup de pub. J'ai envoyé divers e-mails demandant la possibilité d'avoir un accès gratuit à l'API à l'avenir et je n'ai reçu aucune réponse.

Ola PTDreamer, tu es le gars du fer à souder stm32 ! Je n'ai toujours pas fini le mien pour un fer JBC.

J'ai demandé une chose similaire à SnapEDA et ils m'ont répondu 2 mois plus tard (la semaine dernière). Espérons qu'ils soient plus indulgents envers nous.

J'ai reçu une réponse d'Octopart le jour ouvrable suivant confirmant qu'ils prévoyaient d'offrir un niveau gratuit "dans quelques semaines". C'était début juin. Croisons encore les doigts !

Le 2 juillet 2020, à 13h35, Martijn Kuipers [email protected] a écrit :

Ola PTDreamer, tu es le gars du fer à souder stm32 ! Je n'ai toujours pas fini le mien pour un fer JBC.

J'ai demandé une chose similaire à SnapEDA et ils m'ont répondu 2 mois plus tard (la semaine dernière). Espérons qu'ils soient plus indulgents envers nous.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-652979341 , ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/ACADFOKBXDWBKPB2CL3U273RZR5I3ANCNFSM4NHL37GQ .

IDK, je leur ai envoyé un e-mail il y a quelques semaines. Ils ont agi comme s'ils n'avaient jamais entendu parler de Partkeepr... c'est peut-être comme ça qu'ils ont trouvé le projet ?

Ma requête ne concernait pas spécifiquement PartKeepr - j'utilisais également Octopart pour mon application de commande de nomenclature - qui utilise la base de données PartKeepr comme backend. (Kicad2Partkeepr) mais n'ont pas pu l'utiliser depuis qu'ils ont supprimé l'accès à l'API.

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

Le 2 juillet 2020, à 16h23, Michael Fisher [email protected] a écrit :

IDK, je leur ai envoyé un e-mail il y a quelques semaines. Ils ont agi comme s'ils n'avaient jamais entendu parler de Partkeepr... c'est peut-être comme ça qu'ils ont trouvé le projet ?

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-653071390 , ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/ACADFOOBDRUB3YDZBCRQYCTRZSQ6LANCNFSM4NHL37GQ .

Tout d'abord, je dois dire que je n'ai pas inversé le protocole utilisé par PK concernant Octopart. Donc, chaque déclaration ici n'est que ma supposition éclairée.

Soyez prudent avec le numéro de requête API. Je ne sais pas combien de demandes PK commence pour une seule recherche d'une pièce. Il se peut que chaque téléchargement (fiche technique, image, ...) soit un appel API unique. Il en va de même pour les données des distributeurs et autres.
Cela ferait en sorte qu'une seule recherche coûterait au moins 10 requêtes d'API ! Cela signifie qu'après 50 pièces/mois, vous avez atteint la limite.

Si quelqu'un était prêt à vérifier cela, cela nous aiderait tous. Malheureusement, je n'ai pas le temps pour le moment de m'y mettre.

Au fait : j'ai également demandé à Octopart. Ils m'ont dit ceci :

L'API actuelle ne fournit pas d'accès gratuit pour le moment. Je comprends vos inquiétudes et je m'excuse pour la gêne occasionnée. Cependant, je suis heureux de mentionner qu'Octopart lance une nouvelle version qui disposera de l'infrastructure pour un niveau gratuit, espérons-le d'ici la fin de cet été.

Nous espérons vous voir vous inscrire lorsque l'API v4 sera lancée. S'il vous plaît laissez-moi savoir si vous avez des questions.

Je tiens à souligner qu'en raison du manque de puissance de développement, nous ne pourrons peut-être pas utiliser l'API v4 mentionnée d'Octopart.

Au début de cette année, mon inscription à Octopart a été rejetée car mon cas d'utilisation (Partkeeper en tant qu'amateur) n'était pas compatible avec les conditions d'utilisation d'Octopart.
Ces termes mentionnent spécifiquement que vous ne pouvez pas télécharger et stocker des données (comme des fiches techniques) sur votre propre système et toutes les données récupérées d'Octopart ne peuvent être mises en cache que pendant 24 heures maximum. (https://octopart.com/api/terms)
Cela signifie que vous devrez utiliser l'API tout le temps et avec une limite stricte, je ne veux pas que mes projets s'arrêtent lorsque j'atteindrai la limite d'appels API.

Pour PartKeepr en général, je serais plus intéressé par la possibilité d'intégrer d'autres API en plus d'Octopart.
La plupart des distributeurs de pièces fournissent des API à leurs clients pour la récupération des fiches techniques et des informations sur les prix.
Il ne s'agit pas d'une source unique de données agrégées, mais cela signifie qu'il ne s'agit pas non plus d'un point de défaillance ou d'un goulot d'étranglement unique.

Salut à tous,

Mise à jour de ce fil car nous avons lancé la nouvelle API GraphQL que nous sommes
assez excité et peut être trouvé ici: https://octopart.com/api

Quelques mises à jour :

Notre niveau gratuit permet le retour de 500 pièces par mois avec la possibilité de
acheter plus si nécessaire.

Il y aura du travail à faire pour s'assurer que PK peut interroger notre nouveau
API, notre guide de démarrage est disponible ici :
https://octopart.com/api/v4/getting-started.

Si vous êtes préoccupé par la limite de pièces dans le niveau gratuit, je vous recommande d'utiliser
multi_match avec la limite 1 pour s'assurer que chaque correspondance ne renvoie qu'une seule partie.

Nous espérons que les nouvelles fonctionnalités de notre API seront utiles à la communauté PK,
faites le moi savoir si vous avez des questions, vous pouvez m'envoyer un e-mail directement à
[email protected]

-James

Le jeudi 2 juillet 2020 à 12 h 04, Christian [email protected] a écrit :

Tout d'abord, je dois dire que je n'ai pas désosser le protocole que PK
utilisations concernant Octopart. Donc, chaque déclaration ici n'est que ma supposition éclairée.

Soyez prudent avec le numéro de requête API. Je ne sais pas combien de demandes PK
démarre pour une seule recherche d'une pièce. Il se peut que chaque
download (fiche technique, image, ...) est un appel API unique. La même chose est vraie
pour les données des distributeurs, etc.
Cela ferait en sorte qu'une seule recherche coûterait au moins 10 requêtes d'API ! Ce
signifie qu'après 50 pièces/mois, vous avez atteint la limite.

Si quelqu'un était prêt à vérifier cela, cela nous aiderait tous. Malheureusement,

Je n'ai pas le temps pour le moment de m'y mettre.

Au fait : j'ai également demandé à Octopart. Ils m'ont dit ceci :

L'API actuelle ne fournit pas d'accès gratuit pour le moment. je comprends
vos préoccupations et je m'excuse pour la gêne occasionnée. Cependant, je suis heureux de
mentionner qu'Octopart lance une nouvelle version qui aura le
infrastructure pour un niveau gratuit, espérons-le d'ici la fin de cet été.

Nous espérons vous voir vous inscrire lorsque l'API v4 sera lancée. Veuillez me faire savoir si
vous avez des questions.

Je tiens à souligner qu'en raison du manque de puissance de développement, nous pourrions ne pas être
capable d'utiliser l'API v4 mentionnée d'Octopart.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-653094570 ,
ou désabonnez-vous
https://github.com/notifications/unsubscribe-auth/APVO4KJABPVCMTJQSICYJXTRZSVYRANCNFSM4NHL37GQ
.