I think we need to use regex to be case insensitive (same as we did in HTTP API:

Note that supporting just all lower case and all upper case will probably be not good enoug, as I take Get or Post also works

Do you think we should have the same case-insensitive treatment (using regex) for similar cases like authorizer.type and integration?

I think whenever we need to use regexp pattern and expect case insensitive matching, we should use regex instead of pattern

So if it's the case for authorizer.type an integration then, yes

It'll be nice to use same regex as in httpApi event

I believe we expect method and path unconditionally, while above configuration, seem to expect different set of properties exclusively (and most of them do not require method and path), that doesn't look right.

In my understanding, schema for http is either string (in form of method path), or single version of object where method and path are required.

In similar manner as in httpApi event here:

but ofc we will have more properties in case of this event

I declared path as required in baseIntegrationSchema, so all other integration schemas inherit that.
I did fail to declare method as required as well.
The reason I used multiple object schemas instead of one is there many conditions regarding integration types. That is what I referred to when I wrote about if/else - if I go with one object for all integration types, then I would have to use many if/else clauses to declare all constraints.

Indeed, sorry I failed to see, that other objects, share all properties from baseIntegrationSchema

I think it should be awsArnString

Why not simply awsCfInstruction? Are we sure that relying on any other, aside of Ref, intrinsic functions is not supported here?

Let's also set minimum

I think minimum should be 0 because:

If you specify a value greater than 0, API Gateway caches the authorizer responses

Meaning, setting 0 will disable cache. I have no experience with this, but I guess it's a valid option.

Sure, my point was, to not welcome negative values, we should set minimum: 0 I believe

Let's keep alphabetical order

I think it should be minimum 1

One problem with this kind of configuration is that eventual errors will not be informative.

afaik if I declare method: FOO in otherwise perfectly valid configuration, the result error will be: "Unsupported configuration format", with no hint that error is at method property.

It goes from fact, that with such schema it's challenging to resolve which exactly oneOf option was chosen by user. AJV will expose errors resolved for each option, showing all of them will produce unbearable noise (we intentionally convert it then, to one "Unsupported configuration format")

We already had similar cases before, and we decided to configure properties for all options in one level, and leave (or introduce) inline validation that's meaningful for user as e.g. follows:

if (integrationType !== X && authorizer.claims) {
  throw new ServelressError("authorizer.claims is not supported for given integration type");
}

I would also stick here to that.

I believe we should not try to validate any complex interchangeable rules with JSON schema, as it then it becomes a maintenance burden we can't show a meaningful error message to user.

I understand.
I will refactor this PR to have a single schema, and leave the validations needed for the edge cases.

We need to support both forms in case insensitive way

On AWS side it's type Json, does it mean that both forms are accepted, object and string ?

I got confused by the example:

functions:
  create:
    handler: posts.create
    events:
      - http:
          path: posts/create
          method: post
          request:
            schema:
              application/json: ${file(create_request.json)}

I understand now that ${file(create_request.json)} resolves to json (as object) so the string option is not relevant

As I test locally, in this form schema will in most cases fail, we've used oneOf, and no property listed is required (so in most cases both variants match, and that's invalid by schema).

I guess it's not exposed by tests, only because there are no tests that involve this event written with runServerless

Normally we configure such things, by defining involved properties normally in properties section , and use oneOf to configure two different required collections

I think this produces as schema, where we expect an objects with regexp properties.

I believe this should be converted to anyOf list

I used oneOf to be consistent with other places that have .map(caseInsensitive). The array will have distinct patterns, so a value can never match more than one option.

I think we need to wrap it with ^ and $

Let's not distinguish null in schema.

We actually support null at every property (it's treated to be equivalent to undefined or not set at all)

Adding extra recognition is specific schema is not effective in any way

I think we need to also introduce required: [], otherwise we make passing origin required (either via origin or origins option)

It seems to me from the code that indeed one of them is required. We also had this manual validation that I removed which supports my theory.

Indeed, it appears that if someone uses an object form, then not providing origin will fail.

Still that looks as apparent design bug, as by supporting cors: true we indicate that all properties have defaults. Intuitively object form should fall into origin: '*' if one was not set (it's e.g. the case in HTTP API, which has similar cors setting)

Anyway this is side issue (not a concern of this PR) so yes let's leave it as required.