accordproject/apap

Accord Project Agreement Protocol

apap's Issues

Publish prototype version of APAP to accordproject.org

Reference implementation for Agreement Protocol

Publish API Docs to accordproject.org

Alpha release of Agreement Protocol model

Publish stateful version of APAP server

Error generating OpenAPI client from AP OpenAPI specification file.

I've been trying to generate an OpenAPI client using openapi-generator located at: https://openapi-generator.tech.

First tried:

openapi-generator generate -g rust \           
  -i https://github.com/accordproject/apap/blob/main/openapi.json \
  -o accord-rust

However, got errors indicating that the generator was expecting a YAML file.

Therefore, generated YAML file (see attached) by using converter at: https://www.json2yaml.com.

YAML file:
openapi-accord.yaml

Tried this command:

openapi-generator generate -g rust \
  -i ./openapi-accord.yaml \
  -o accord-rust

and got below errors.

errors.txt

Tried a few different generators (e.g. typescript-node) just in case it was something to do with the rust generator but same errors occurred.

Concerto to OpenAPI specification transformation

Language Choice for Reference Implementation

JSON Schema generated code accepts different payload to Ergo

Hi @mttrbrts

The JSON was hand-crafted by yours truly in order to match the Rust code's expectation.

This is my logic.

The schema.json file generated by Cicero contains the snippet for the MyRequest object is as follows:

    "org.accordproject.helloworld.MyRequest": {
      "title": "MyRequest",
      "description": "An instance of org.accordproject.helloworld.MyRequest",
      "type": "object",
      "properties": {
        "$class": {
          "type": "string",
          "default": "org.accordproject.helloworld.MyRequest",
          "pattern": "^org\\.accordproject\\.helloworld\\.MyRequest$",
          "description": "The class identifier for org.accordproject.helloworld.MyRequest"
        },
        "input": {
          "type": "string"
        }
      },
      "required": [
        "$class",
        "input"
      ]
    },

The bit that we really only care about is the "properties" object above.

The Rust that was generated from this snippet is;

#[derive(Serialize, Deserialize)]
pub struct OrgAccordprojectHelloworldMyRequestProperties {
    #[serde(rename = "$class")]
    class: Class,
    input: Name,
}

#[derive(Serialize, Deserialize)]
pub struct Class {
    #[serde(rename = "type")]
    class_type: String,
    #[serde(rename = "default")]
    class_default: String,
    pattern: String,
    description: String,
}

#[derive(Serialize, Deserialize)]
pub struct Name {
    #[serde(rename = "type")]
    name_type: String,
}

This Rust code looks sensible to me when compared to the the JSON Schema above.

I hand-crafted the JSON Request object, based on the JSON Schema and Rust code.

When I pass in the below JSON Request object, the code works fine. :-)

{
    "$class": {
        "type": "string",
        "default": "org.accordproject.helloworld.MyRequest",
        "pattern": "^org\\.accordproject\\.helloworld\\.MyRequest$",
        "description": "The class identifier for org.accordproject.helloworld.MyRequest"
    },
    "input": {
        "type": "Accord Project"
    }
}

When I pass the JSON object that is used by Ergo then it fails.

{
    "$class": "org.accordproject.helloworld.MyRequest",
    "input": "Accord Project"
}

The only way I can get the original JSON MyRequest object to work is if I change the Rust code to be:

#[derive(Serialize, Deserialize)]
pub struct OrgAccordprojectHelloworldMyRequestProperties2 {
    #[serde(rename = "$class")]
    class: String,
    input: String,
}

That is, ditch the Class and Name objects and use simple String types instead.

Everything above looks fine to me. It's just that I can't see how Ergo is executing this model, unless Ergo is interpreting the Concerto CTO file differently to JSON Schema.

What am I missing?

JSON to Runtime Binding for Reference Implementation