Consider exposing programmatic API ala AnkiConnect in rslib

[dae]

Could be shared by the various clients, allowing other apps to do things like add cards to Anki in a platform-independent way.

Some things to consider:

• Some form of access control, so that random apps or websites can't post changes to an open port. Global/more fine-grained?
• Protobuf, or JSON. JSON is less work for us at the Rust layer, easier for beginner developers to understand conceptually, and does not require extra build steps. Downsides are consumers could not rely on code generation for API, and the API would be described via Rust code instead of the somewhat-simpler .proto files.

[aehlke]

I'm an iOS app dev that would use this, but I don't understand the use case - this would be for Anki users who are adept at setting up home networking and exposing their home computer to the public internet? Or only for other desktop and web apps running on the same machine, but not mobile apps without exposing a home server?

[dae]

I've replied on your forum post: https://forums.ankiweb.net/t/suggestion-extensionkit-as-next-gen-replacement-for-url-schemes/30582

[mainrs]

Hello! I am working on Learning with Text and wanted to integrate with Anki properly. As far as I can tell, I cannot simply use rslib as a git dependency in a Rust project and expect it to be able to read the Anki database and fetch cards of specific decks and their learning status, can I?

What is the goto way to fetch information from Anki right now? My program is written in Rust.

[dae]

The Rust crate should be usable in other crates, though please note you'd need to license your project under an AGPL-compatible license.

[andrewsanchez]

Downsides are consumers could not rely on code generation for API, and the API would be described via Rust code instead of the somewhat-simpler .proto files.

You can start with an OpenAPI spec (or potentially generate it from the API code) that can be used to generate API docs. https://swagger.io/docs/specification/about/

Starting with an OpenAPI spec has the advantage of allowing you to generate the stubs for the API code and even client libraries. Downside is that you may have to maintain the spec.

[aehlke]

OpenAPI is the way to go - instant client libraries supporting the latest async and so on language features in every target language and platform. There are a variety of tools that help generate OpenAPI spec from other sources of truth in your application.

JSON API can also be used within OpenAPI: https://apisyouwonthate.com/blog/json-api-openapi-and-json-schema/

[dae]

Anki already makes heavy use of protobuf, so if we are going down the codegen route, it's an easier sell than pulling in another dependency.

[aehlke]

EDIT: Sorry just noticed that I linked something that is marked as BETA. Disregard the link. However the openapi-generator tool is a useful reference for generating native client wrappers. But it is not usable for protobuf yet.

@dae I like the quality of the openapi-generator library, which has protobuf -> openapi spec support. Here's a protobuf config from their sample project: https://github.com/OpenAPITools/openapi-generator/blob/d99affda96d32de1b689e1e316c6e3d6163a1a6c/samples/config/petstore/protobuf-schema/services/pet_service.proto I haven't tried protobuf -> openapi so I don't know what that looks like or what the value is in it. I could investigate that use case.

Config docs: https://github.com/OpenAPITools/openapi-generator/blob/d99affda96d32de1b689e1e316c6e3d6163a1a6c/docs/generators/protobuf-schema.md

Looks like it might produce native client code that hides the protobuf usage. Haven't found which clients support it.