[WIP | Spec] Protobuf File about ocis-hello HOT 3 OPEN

The paths for the generated http post endpoints have the primary requirement to be unique, secondary requirement to be developer friendly. They do not have the requirement to adhere RESTful design.

We decided to go with paths like shown in the following example. The generated http endpoints will never be visible for developers, as they are internally used in the generated JavaScript client. For debugging purposes it might still be useful to have human readable paths.

service ValueService {
  rpc SaveSettingsValue(SaveSettingsValueRequest) returns (SaveSettingsValueResponse) {
    option (google.api.http) = {
      post: "/api/v0/settings/value-save",
      body: "*"
    };
  };
  rpc GetSettingsValue(GetSettingsValueRequest) returns (GetSettingsValueResponse) {
    option (google.api.http) = {
      post: "/api/v0/settings/value-get",
      body: "*"
    };
  };
  rpc ListSettingsValues(ListSettingsValuesRequest) returns (ListSettingsValuesResponse) {
    option (google.api.http) = {
      post: "/api/v0/settings/values-list",
      body: "*"
    };
  };
}

from ocis-hello.

One drawback of this is, that the returned status codes have to be handled and will probably not be what a developer would expect. E.g. a successful get request in the above style would not return http 200, but http 201.

from ocis-hello.

@refs what's the state of things here currently? The repo has experienced quite some changes I assume

from ocis-hello.