4 ms·

The documentation states 'automatically populate based on JSON requests that fire as you browse the web' so does this mean that gRPC protobuf are not captured?

mrmagoo2 3y ago
Anything that isn't a JSON request is specifically ignored.
- mdaniel 3y ago
  I saw your sibling comment about "keeping it simple," however that is a bit counter to "generates OpenAPI specifications" since those for sure are not limited to just application/json request/response bodies I wanted to draw your attention to "normal" POST application/x-www-form-urlencoded <https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/versions/3.1.0.md#support-for-x-www-form-urlencoded-request-bodies https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/vers...> and its multipart/form-data friend <https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/versions/3.1.0.md#special-considerations-for-multipart-content https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/vers...> The latter is likely problematic, but the former is in wide use still, including, strangely enough, the AWS API, although some of their newer services do have an application/json protocol I know that's a lot of words, but the tl;dr would be that if you want your extension to be application/json only, then changing the description to say "OpenAPI specifications for application/json handshakes" would help the consumer be on the same page with your goals
  - mrmagoo2 3y ago
    You raise a good point and it would be great to account for this. I will take a look at this. Excellent suggestion.
jcrites 3y ago
Does gRPC /ProtoBuf have support for web browsers? I don't know of a situation where I'd encounter those in a web application.
- voidmain0001 3y ago
  https://blog.envoyproxy.io/envoy-and-grpc-web-a-fresh-new-alternative-to-rest-6504ce7eb880 https://blog.envoyproxy.io/envoy-and-grpc-web-a-fresh-new-al...

mrmagoo2 3y ago

Anything that isn't a JSON request is specifically ignored.

mdaniel 3y ago
I saw your sibling comment about "keeping it simple," however that is a bit counter to "generates OpenAPI specifications" since those for sure are not limited to just application/json request/response bodies I wanted to draw your attention to "normal" POST application/x-www-form-urlencoded <https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/versions/3.1.0.md#support-for-x-www-form-urlencoded-request-bodies https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/vers...> and its multipart/form-data friend <https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/versions/3.1.0.md#special-considerations-for-multipart-content https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/vers...> The latter is likely problematic, but the former is in wide use still, including, strangely enough, the AWS API, although some of their newer services do have an application/json protocol I know that's a lot of words, but the tl;dr would be that if you want your extension to be application/json only, then changing the description to say "OpenAPI specifications for application/json handshakes" would help the consumer be on the same page with your goals
- mrmagoo2 3y ago
  You raise a good point and it would be great to account for this. I will take a look at this. Excellent suggestion.

jcrites 3y ago

Does gRPC /ProtoBuf have support for web browsers? I don't know of a situation where I'd encounter those in a web application.

voidmain0001 3y ago
https://blog.envoyproxy.io/envoy-and-grpc-web-a-fresh-new-alternative-to-rest-6504ce7eb880 https://blog.envoyproxy.io/envoy-and-grpc-web-a-fresh-new-al...