Use GET for service discovery

[slinkydeveloper]

Fix #1259

[slinkydeveloper]

This one doesn't break anything, as both SDKs are not checking the method used to invoke service discovery.

[igalshilman]

@slinkydeveloper Looks good to me.
Also using GET allows caching, which is okay for us (I think)

But just as an abundance of caution, let me ask @jackkleeman or @pcholakov if this might have any effect on lambda? (i'd assume not, but just to make sure)

[pcholakov]

I'd assume not, provided the SDK deals with it the same regardless of the invocation transport. Since Lambda just takes a JSON payload blob natively, we just shove the request into an API Gateway HTTP request event, and then unpack it on the handler side. If I'm reading this[^1] correctly, we disregard the method altogether when we pass the inbound request from the Lambda-specific to the generic invoke handler in the TS SDK.

[1] https://github.com/restatedev/sdk-typescript/blob/main/packages/restate-sdk/src/endpoint/lambda_handler.ts#L55-L110

[pcholakov]

Ditto for the Java SDK, just had a quick look; I don't think anything at all cares about the HTTP method specified in the payload.

[igalshilman]

Thanks a lot @pcholakov.
Then LGTM!

[tillrohrmann]

@slinkydeveloper Looks good to me. Also using GET allows caching, which is okay for us (I think)

Could caching become a problem if one deploys a new service container and then one would get a stale discovery response?

[tillrohrmann]

LGTM. +1 for merging.

[slinkydeveloper]

Could caching become a problem if one deploys a new service container and then one would get a stale discovery response?

In theory the discovery response is immutable for a given service endpoint. In any case, none of our components do caching of GET requests, at most it will be some 3rd party proxy, and if that becomes an issue we can fix it by using a combination of headers, e.g. https://stackoverflow.com/questions/10927766/force-http-request-to-not-cache