Skip to content

Commit

Permalink
Fix some broken docs links
Browse files Browse the repository at this point in the history
Fixes #1836
  • Loading branch information
johanbrandhorst committed Nov 23, 2020
1 parent 370d869 commit 9acd24b
Show file tree
Hide file tree
Showing 4 changed files with 37 additions and 25 deletions.
26 changes: 14 additions & 12 deletions docs/docs/mapping/customizingopenapioutput.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ message ABitOfEverything {
Operations can also be customized:

```protobuf
service ABitOfEverythingService {
service ABitOfEverythingService {
rpc Delete(grpc.gateway.examples.internal.proto.sub2.IdMessage) returns (google.protobuf.Empty) {
option (google.api.http) = {
delete: "/v1/example/a_bit_of_everything/{uuid}"
Expand Down Expand Up @@ -92,10 +92,10 @@ message MyMessage {

The following options are used in the Open API output:

* `REQUIRED` - marks a field as required
* `OUTPUT_ONLY` - marks a field as readonly
- `REQUIRED` - marks a field as required
- `OUTPUT_ONLY` - marks a field as readonly

Google defines a couple other options - `OPTIONAL`, `IMMUTABLE`, `INPUT_ONLY` - that are not currently used. `OPTIONAL` support is currently under discussion in [this issue](https://github.com/grpc-ec system/grpc-gateway/issues/669). For `IMMUTABLE` and `INPUT_ONLY` fields, there is an [open issue](https://github.com/OAI/OpenAPI-Specification/issues/1497) in the Open API specification for adding functionality for write once or immutable fields to the spec.
Google defines a couple other options - `OPTIONAL`, `IMMUTABLE`, `INPUT_ONLY` - that are not currently used. `OPTIONAL` support is currently under discussion in [this issue](https://github.com/grpc-ecosystem/grpc-gateway/issues/669). For `IMMUTABLE` and `INPUT_ONLY` fields, there is an [open issue](https://github.com/OAI/OpenAPI-Specification/issues/1497) in the Open API specification for adding functionality for write once or immutable fields to the spec.

# Using go templates in protofile comments

Expand Down Expand Up @@ -173,14 +173,16 @@ The content of `tables.md`:

```markdown
## {{.RequestType.Name}}
| Field ID | Name | Type | Description |
| ----------- | --------- | --------------------------------------------------------- | ---------------------------- | {{range .RequestType.Fields}}
| {{.Number}} | {{.Name}} | {{if eq .Label.String "LABEL_REPEATED"}}[]{{end}}{{.Type}} | {{fieldcomments .Message .}} | {{end}}


| Field ID | Name | Type | Description |
| ----------- | --------- | --------------------------------------------------------- | ---------------------------- | {{range .RequestType.Fields}}
| {{.Number}} | {{.Name}} | {{if eq .Label.String "LABEL_REPEATED"}}[]{{end}}{{.Type}} | {{fieldcomments .Message .}} | {{end}}

## {{.ResponseType.Name}}
| Field ID | Name | Type | Description |

| Field ID | Name | Type | Description |
| ----------- | --------- | ---------------------------------------------------------- | ---------------------------- | {{range .ResponseType.Fields}}
| {{.Number}} | {{.Name}} | {{if eq .Label.String "LABEL_REPEATED"}}[]{{end}}{{.Type}} | {{fieldcomments .Message .}} | {{end}}
| {{.Number}} | {{.Name}} | {{if eq .Label.String "LABEL_REPEATED"}}[]{{end}}{{.Type}} | {{fieldcomments .Message .}} | {{end}}
```

## OpenAPI output
Expand All @@ -189,13 +191,13 @@ The content of `tables.md`:

This is how the OpenAPI file would be rendered in [Swagger UI](https://swagger.io/tools/swagger-ui/)

![Screenshot OpenAPI file in SwaggerUI](../assets/images/gotemplates/swaggerui.png)
![Screenshot OpenAPI file in SwaggerUI](../../assets/images/gotemplates/swaggerui.png)

### Postman

This is how the OpenAPI file would be rendered in [Postman](https://www.getpostman.com/)

![Screenshot OpenAPI file in Postman](../assets/images/gotemplates/postman.png)
![Screenshot OpenAPI file in Postman](../../assets/images/gotemplates/postman.png)

For a more detailed example of a protofile that has Go templates enabled,
[see the examples](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/internal/proto/examplepb/use_go_template.proto).
Expand Down
5 changes: 0 additions & 5 deletions docs/docs/mapping/customizingyourgateway.md
Original file line number Diff line number Diff line change
Expand Up @@ -258,11 +258,6 @@ To override error handling for a `*runtime.ServeMux`, use the
`runtime.WithErrorHandler` option. This will configure all unary error
responses to pass through this error handler.
See https://mycodesmells.com/post/grpc-gateway-error-handler for an example
of writing a custom error handler function. Note that this post targets
the v1 release of the gateway, and you no longer assign to `HTTPError` to
configure an error handler.
## Stream Error Handler
The error handler described in the previous section applies only
Expand Down
27 changes: 21 additions & 6 deletions docs/docs/mapping/grpcapiconfiguration.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,15 +27,30 @@ NOTE: the same option is also supported by the `gen-openapiv2` plugin.

## Using an external configuration file

Google Cloud Platform offers a way to do this for services hosted with them called ["gRPC API Configuration"](https://cloud.google.com/endpoints/docs/grpc/grpc-service-config). It can be used to define the behavior of a gRPC API service without modifications to the service itself in the form of [YAML](https://en.wikipedia.org/wiki/YAML) configuration files.

grpc-gateway generators implement the [HTTP rules part](https://cloud.google.com/endpoints/docs/grpc-service-config/reference/rpc/google.api#httprule) of this specification. This allows you to take a completely unannotated service proto file, add a YAML file describing its HTTP endpoints and use them together like a annotated proto file with the grpc-gateway generators.

OpenAPI options may also be configured via ["OpenAPI Configuration"](https://github.com/grpc-ecosystem/grpc-gateway/tree/master/internal/descriptor/openapiconfig/openapiconfig.proto) in the form of YAML configuration files.
Google Cloud Platform offers a way to do this for services
hosted with them called
["gRPC API Configuration"](https://cloud.google.com/endpoints/docs/grpc/grpc-service-config).
It can be used to define the behavior of a gRPC API service
without modifications to the service itself in the form of
[YAML](https://en.wikipedia.org/wiki/YAML) configuration files.

grpc-gateway generators implement the
[HTTP rules part](https://cloud.google.com/endpoints/docs/grpc-service-config/reference/rpc/google.api#httprule)
of this specification. This allows you to take a completely
unannotated service proto file, add a YAML file describing
its HTTP endpoints and use them together like a annotated
proto file with the grpc-gateway generators.

OpenAPI options may also be configured via
["OpenAPI Configuration"](https://github.com/grpc-ecosystem/grpc-gateway/tree/master/internal/descriptor/openapiconfig/openapiconfig.proto) in the form of YAML configuration files.

### Usage of gRPC API Configuration YAML files

The following is equivalent to the basic [usage example](usage.html) but without direct annotation for grpc-gateway in the .proto file. Only some steps require minor changes to use a gRPC API Configuration YAML file instead:
The following is equivalent to the basic
[`README.md`](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/README.md#usage)
example but without direct
annotation for grpc-gateway in the .proto file. Only some steps require minor
changes to use a gRPC API Configuration YAML file instead:

1. Define your service in gRPC as usual

Expand Down
4 changes: 2 additions & 2 deletions docs/docs/mapping/patch.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,13 +18,13 @@ There are two scenarios:
- The FieldMask is hidden from the REST request as per the
[Google API design guide](https://cloud.google.com/apis/design/standard_methods#update)
(as in the first additional binding in the
[UpdateV2](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/internal/proto/examplepb/a_bit_of_everything.proto#L366)
[UpdateV2](https://github.com/grpc-ecosystem/grpc-gateway/blob/370d869f65d1ffb3d07187fb0db238eca2371ce3/examples/internal/proto/examplepb/a_bit_of_everything.proto#L428-L431)
example).
In this case, the FieldMask is updated from the request body and
set in the gRPC request message.
- The FieldMask is exposed to the REST request (as in the second
additional binding in the
[UpdateV2](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/internal/proto/examplepb/a_bit_of_everything.proto#L370)
[UpdateV2](https://github.com/grpc-ecosystem/grpc-gateway/blob/370d869f65d1ffb3d07187fb0db238eca2371ce3/examples/internal/proto/examplepb/a_bit_of_everything.proto#L432-L435)
example).
For this case, the field mask is left untouched by the gateway.

Expand Down

0 comments on commit 9acd24b

Please sign in to comment.