ipinfo / libraries Goto Github PK

The spec for the user-agent says it should be IPInfoClient/Language/Version. Is that version of the language or version of the API/wrapper-spec/something else? I'm guessing language?

So for Python 3.6 it would be IPInfoClient/Python/3.6

Many users will be hearing about our service for the first time when they come across one of the libraries, so we should make sure we introduce the service, explain what we do and how to signup for a token etc. We can create a standard header and footer for the READMEs that we use across all libraries.

The Okta libs do this really well, with a getting started section etc https://www.npmjs.com/package/@okta/okta-auth-js

Some other good examples:

• https://github.com/sudiptpa/ipstack
• https://github.com/mbuckbee/IP-Investigator-Gem

I'm a little bit lost on the bot behavior.

”The library should provide a middleware to detect if the traffic is coming from a suspected bot or a user"

Can someone explain how this works? If I'm making the generic Python wrapper that's initiating a request to the IPInfo API, it's not clear to me where a potential bot fits in.

After quickly investigating our C# SDK https://github.com/ipinfo/csharp, it looks like the library is quite complete. It already has support for batch ops, all the new data we have, async, etc.

It's currently listed as Proposed so we should upgrade that.

All headers in our library README files mention the old 1k/day limit rather than the new higher 50k/mo req limit. Update everything including the template in this repo.

(thanks to @kuntoaji for noting).

The OpenAPI spec made by @HavenDV is at https://github.com/ipinfo/csharp/blob/master/docs/openapi.yaml - it would be nice for us to have this in a library-agnostic place, like this repo, and used to generate stuff later if we need it.

Discussion point: Should the library provide country code => country name conversion?

It should be stated in the specs under which license(s) the libraries/packages/plugins must be released.

Also it must contain the requirements to the source code, e.g. LICENSE file, comments in the code files, statement in the README file, etc.

Thoughts on notes on https://github.com/aaomidi/ipinfo-wrapper-specs/blob/master/versions/01/GUIDELINES.md

Generally, the guidelines look great! They currently seem to be more focused towards an external audience, but I think it'd be easier for us to create internal focused guidelines for our own official libraries initially, and then create a modified version of that for an external audience after. It gives us less to worry about initially, will make it easier to make changes, and means we can publish public guidelines after we've learnt some lessons from building a few libraries.

The first obvious change based on that approach would be that we don't need to worry about a vendor, so the user agent can just be:

IPInfoClient/Language/Version

For caching I'd set the default to 1h instead of 1m (or perhaps even 24h), but it should definitely be easily configurable.

We should have generic filtering too, not just for bot traffic. We need to think about we're going to get all of attributes at request time (eg. where does the user agent come from). Maybe the filtering only makes sense for libraries for specific frameworks where we'll clearly have access to the useragent or a request object or something, rather than something like a Go library, where we can only expect the user to pass in an IP, and let them do fitlering themselves in the code?

Discussion point: What level of caching implementation should we provide?