when the apicurio registry will work with apicurio studio

[Yuutakasan]

When will the apicurio registry be a stable release at this time? When will you start working with apicurio studio again?

[EricWittmann]

I think it will always be a balancing act between all of the Apicurio projects going forward. That said, I think we'll be doing an upstream Registry release fairly soon (1.3.0.Final) and then we can hopefully find a more equitable balance of working between the two projects. Part of that will be some work I need to do in prioritizing the roadmaps of both projects. But I think the sands will always be shifting because that's always the way it is with software! At least in my experience.

I know it can be frustrating for users - it is for me too. :)

[Yuutakasan]

Thanks for the reply, Eric.

I was wondering when I should recommend to a customer who installed Apicurio Studio last year to upgrade and install the Apicurio Registry, as I was wondering if it would be possible to support Japaneseization and install the Apicurio Registry. After using Apicurio Studio, I thought there were some issues with schema sharing and schema-related validation across the project, so I definitely wanted to implement the Apicurio Registry and use it myself.

I understood that it was going to take a bit more time to get it up and running. It's hard to send a pull request from us when there is such a big architectural change, so I'll wait for it to be integrated.

I think the Apicurio Studio team is really doing a great job. Thank you.

[EricWittmann]

I would be interested to know what your expectations would be regarding integration between Registry and Studio. We're still working that out ourselves and it would be very good to have other perspectives.

The way I think about Registry right now is that it is very much a runtime component when used for Kafka use-cases (as a Schema Registry). In the API Design world, I was thinking that the Registry could be a place where potential consumers of APIs could see a catalog of what was available within an existing enterprise/organization. In that scenario, Registry is actually quite separate from Studio, because Studio is used as design time, while Registry would be populated after an API was actually implemented, tested, and deployed.

So I'd love to hear what your expectations/use-cases might be!

[Yuutakasan]

Maybe my understanding is wrong, please let me know if I'm wrong.

The apicurio-registry registers data schemas and validators such as JSON Schema, Kafka Connect schema, WSDL, XML Schema (XSD), etc. along with OpenAPI Spec.

There are three things that I have trouble with using Apicurio. The first problem is that Apicurio has difficulty creating a dictionary of internal data schemas that are often used for products, customers, etc. Once the API is up and running, you don't want to change it too much afterwards, but when you have several engineers working on it, the development is based on what they know, which makes it difficult to use There are times when the schema is designed around the task at hand, and even though the APIs handle similar information, there are countless patterns in the number of items, naming methods, data types, etc. Also, different data validation leads to different quality data being registered and different quality data being registered by APIs.

I think this can be solved by using Apiregistry as a schema dictionary.

The second problem is that editing a single OpneAPI Spec is easy to edit, but it's hard to adapt and update when you have a common schema standardized and managed across multiple OpneAPI Spec.

For example, let's say you are managing multiple OpneAPI Spec in the same organization and you have made a rule to add the following metadata.

{
    "metadata": {
        "resultset": {
            "count": 227,
            "offset": 25,
            "limit": 25
        }
    },
    "results": []
}

In that case, if you changed all the API metadata, for example the following, Apicurio would have to spend a lot of effort to re-modify all the files.

{
    "metadata": {
        "count": 227,
        "offset": 25,
        "limit": 25
    },
    "results": []
}

I use Apicurio to promote standardization activities by adapting our internal standardization rules by customizing the Validation function while asking developers to create OpenAPISpec with lower learning costs. Standardization does not end once a decision is made, but at least once a year we need to revise the standardization documents to make them better, and at that time the schema may change.

At that time, it would be nice to be able to change all APIs without hassle. We think that Apiregistry can be used as a schema dictionary for this purpose.

The third problem is that I can't register data validations.

I think the first and third problems could be solved if there was a mechanism to search for schemas registered in the Api-registry when creating, for example, Data Types, and apply them. The second problem can be solved if there is a UI that notifies you when there is a change in the adapted apicurio-registry schema.

[EricWittmann]

This is really good feedback - thank you. I've been thinking about it in a slightly different way. The goal for Studio was to make it a place to edit OpenAPI documents and other types such as JSON Schema, Avro, AsyncAPI, etc. Essentially, if you can register the type in the Registry, then I think Studio should be able to edit it.

For this specific use-case, you should be able to manage all of your common data types in a centralized file (or set of files) within Studio, and then reference them from your API Designs (OpenAPI and AsyncAPI). This is actually possible today in the editor by importing types:

Support for this is still rather preliminary, but you can get an idea of what we're aiming for longer term.

But using this feature would solve the problem of having to modify a bunch of API Designs every time a core data type changes. There is still the open question of how and when to register these resources with the Registry.

Admittedly I think there are a host of Studio features that all work together to make this experience better for users. This includes the long-desired organization/team features, versioning or snapshoting of API designs, editors for JSON Schema and AsyncAPI, etc.

All of that said - it's an interesting idea to add support for importing types directly from the Registry. I'll need to give that some thought!

[Yuutakasan]

I thought I was using Apicurio Studio quite a bit, but I wasn't aware of this feature. Well, this seems to solve a few of my use cases. So useful!

I understand that this feature would allow us to support changes to the common schema by creating one API to manage the base schema and announcing that we should always import the base schema before working on it.

If we can work with it from Studio, I think we will have more issues to solve. For example, you can host multiple APIcurio in different organizations, but only share the results of vocabulary and validation rules.

Every organization has trouble with common data schemas, and various vocabularies such as schema.org, NIEM, ISA, IMI, etc. are being maintained and created day and night.

The api registry is not only an API, but also a registry for vocabulary data, and I hope that this system can be used to create a basic dataset for everyone to use.

schema.org https://schema.org/ NIEM https://www.niem.gov/ ISA https://ec.europa.eu/isa2/solutions/core-vocabularies_en IMI https://imi.go.jp/goi/imi-about-en/

Government Interoperability Framework “Infrastructure for Multilayer Interoperability (IMI)” https://www.ipa.go.jp/files/000042516.pdf