Applying a Spec resource from standard input doesn't upload the spec

[jonblack]

Given the following Spec resource in the file resource.yaml:

apiVersion: apigeeregistry/v1
items:
  - apiVersion: apigeeregistry/v1
    kind: Spec
    metadata:
      name: reg-supplier
      parent: apis/reg-supplier/versions/1.0.0
    data:
      filename: regsupplier-app/target/openapi.json

It's successfully published to the registry when running:

registry apply -f resource.yaml

When applying the resource from standard input the specification is created with the filename in the resource; however, the specification content is not published.

RESOURCE=$(cat resource.yaml)
echo "$RESOURCE" | registry apply -f -

GetApiSpecContents when using gRPC UI returns the following:

{
  "content_type": "",
  "data": "",
  "extensions": []
}

I would expect the specification content to be uploaded when applying from standard input.

[theganyo]

I agree, it seems intuitive that the content should be included, however the issue with this is that as the input is simply a byte stream which could be coming from anywhere - including even a non-file based resource, there is no base path to use to derive the referenced filename: regsupplier-app/target/openapi.json in the resource.yaml.

[jonblack]

That makes sense. In that case, I would expect some kind of error response because it's guaranteed never to work but fails quite silently. Perhaps the Spec resource shouldn't be supported via stdin. It would be possible if you could inline the spec in the resource, but I recall a previous issue (can't find it right now) where it was decided not to support this.

[theganyo]

I agree, it absolutely shouldn't fail silently. There should be at least a warning, or perhaps an error with the ability to override.

As for inlining, I'm not sure where that was decided against, either. It was mentioned as an option with potential drawbacks in this earlier superceded issue (#228), but I don't see any discussion or decision on that or later against it. It doesn't seem untenable.