Add new service annotation - `@Method(GET|POST|PUT|...)`

[artem-v]

Add support of optional service annotation @Method with value as HTTP method. Must be defined only on methods with annotation @ServiceMethod.

Idea is to support clients who wants to call scalecube service through the HTTP gateway and to support http methods RESTful semantic.

Expected changes

• There must be new enum type in scalecube-services-api with all http methods.
• ServiceReference, ServiceMethodDefinition objects must have method field (optional).
• Add logic to our "out-of-the-box" routers (RandomServiceRouter and RoundRobinServiceRouter) so they begin to support method in the routing logic.

Depends on

https://github.com/scalecube/scalecube-services/issues/856

[artem-v]

Depends on https://github.com/scalecube/scalecube-services/issues/856

[aharonha]

Consider moving the routing strategy from "client" side to discovery layer

[artem-v]

Consider moving the routing strategy from "client" side to discovery layer

Plz elaborate more on this.

[aharonha]

When invoking service to service call, the caller (in this case a service acts like a client) uses the routing strategy (e.g. round-robin, random) based on the annotations, but IMHO the discovery layer should handle it. by that I mean that the service cluster discovery would do the load balancing and routing. This kind of architecture is what k8s calls service while service instances are called pods I remember this part in scalecube from ages ago, and it bothered me back then. When using RESTful approach in a stateless cluster, and the data layer is separated, a client code should not be bothered on which instance to call, but as far as I remember - in the current implementation it does.

And as always it is great to collaborate once again 😄

[artem-v]

And as always it is great to collaborate once again 😄

Yes, Im also glad to see you and your comments (despite that I don't agree with them) : ))

When using RESTful approach in a stateless cluster, and the data layer is separated, a client code should not be bothered on which instance to call

Yes, this is how to it works today, we don't bother which service instance to call. When RESTful support will be implemented on HTTP gateway, it will not be "shift in paradigms" "this change everything", no, it will be just a good extension of HTTP gateway, i.e those who loves RESTful approach will be able to write services in RESTful approach.

but as far as I remember - in the current implementation it does.

No, it never was like that.

by that I mean that the service cluster discovery would do the load balancing and routing.

In scalecube it's different philosophy, we let client to choose load balancing and routing strategies. If he doesn't want to deal with that, fine, round-robin will be used. If default round-robin is a concern, then no problem - implement consistent-hashing, or least-resources load-balancing. I.e philosophy is to - don't centralize decision making, delegate responsibility if it's "delegatable".