I'm not sure any answer other than "I felt like it was a good choice" is gonna be 100% accurate, but a few things, some of which are speculative, some of which are reactionary.
(I'm sadly not very familiar with OAS, so it's very possible that OAS supports many of the things I'm going for!)
- This takes very heavily after protos, which use a DSL.
- This rejects protos because of a few reasons, not the least of which is that every field in proto3 is optional. While it makes sense for google, I don't think it makes sense for everybody.
- gRPC is non-http, and I was unhappy with gRPC-web
- I wanted it to be a terse specification, such that just glancing over the definition file gives you a sense of what the API consists of.
- I wanted a solution that handled websockets/server push as a first-class citizen, and not as a secondary add-on
- I wanted to provide library-level validation of request / response shape.
- I wanted to extend it beyond typescript, notably into python (and hopefully beyond)
- I like the idea of generic structs and oneofs (which I'm going to implement in some future version). I think if we had an easy way to define generics in cross-language APIs, we'd probably use it a fair amount.
- I like the idea of having an extensible language, e.g. be able to provide a JSONLogic type. Imagine a field `priceCalculation: JsonLogic<string, number>`. That'd be pretty cool!
(I'm sadly not very familiar with OAS, so it's very possible that OAS supports many of the things I'm going for!)
- This takes very heavily after protos, which use a DSL.
- This rejects protos because of a few reasons, not the least of which is that every field in proto3 is optional. While it makes sense for google, I don't think it makes sense for everybody.
- gRPC is non-http, and I was unhappy with gRPC-web
- I wanted it to be a terse specification, such that just glancing over the definition file gives you a sense of what the API consists of.
- I wanted a solution that handled websockets/server push as a first-class citizen, and not as a secondary add-on
- I wanted to provide library-level validation of request / response shape.
- I wanted to extend it beyond typescript, notably into python (and hopefully beyond)
- I like the idea of generic structs and oneofs (which I'm going to implement in some future version). I think if we had an easy way to define generics in cross-language APIs, we'd probably use it a fair amount.
- I like the idea of having an extensible language, e.g. be able to provide a JSONLogic type. Imagine a field `priceCalculation: JsonLogic<string, number>`. That'd be pretty cool!