Я перевожу сервис на основе REST с сериализацией json на сервис на основе grpc с сериализацией protobuf.Это Java-сервис.У меня есть некоторые ресурсы в проекте, который выглядит примерно так (пример приведен ниже):
ProductResource.java (v1/Products)
1. GetProduct (v1/Products/Get)
2. UpsertProduct (v1/Products/Upsert)
3. Delete Product (v1/Products/delete)
SupermarketResource.java (v1/SuperMarket)
1. GetShopkeepers (v1/SuperMarket/GetShopkeepers)
2. GetAllProducts ""
3. UpsertShopkeepers ""
В моем текущем проекте на основе REST у меня есть два класса ресурсов - ProductResource и SupermarketResource,Я могу добавить больше методов ресурсов в этих классах.У меня есть два варианта при переводе их в grpc, у меня есть два варианта для моделирования моих прото-файлов для вышеуказанного,
- resource.proto - Все ресурсы в одном прото-файле
rpc GetProduct (Request) returns (Response);
rpc UpsertProduct (Request) returns (Response);
..
..
rpc GetShopkeepers (Request) returns (Response)
..
Когда я использую компилятор protoc для генерации заглушек, это создаст класс impl с именем resourceImpl.java, где я могу реализовать все свои методы rpc.Меня беспокоит то, что класс impl становится действительно большим благодаря реализации всего метода rpc в одном классе.Итак, мне нужно переместить реализацию методов в отдельные классы-обработчики, чтобы код в классе
Product.Я могу реализовать все свои методы RPC.Правильно ли создавать несколько прототипов для каждого ресурса?
Google говорит в своей документации:
Мы рекомендуем один файл на службу с соответствующим запросом и ответами.Подумайте об имени этого файла .proto.Для файлов прото только с ресурсами, попробуйте назвать этот файл просто как resources.proto.
Но тогда они, похоже, не всегда следуют этому в своих собственных API (например, https://github.com/googleapis/googleapis/tree/master/google/streetview/publish/v1)
В их документации не указано, как обрабатывать более одного ресурса в одном сервисе, чтобы сгенерированный код был чище - https://cloud.google.com/apis/design/resource_names
Какая оптимальная структура проекта? У нас около 6-7классы ресурсов в настоящее время имеют 2-3 метода ресурсов в каждом из них, и их число не увеличивается слишком быстро / быстро. Любые ссылки на проекты с открытым исходным кодом также были бы весьма полезны для ссылки.