Add REST endpoint for listing available message protocols

[magnusbaeck]

Description

When starting to use REMReM Generate I relied solely on the Swagger UI but was puzzled by the message protocol path component whose expected value wasn't documented anywhere. I eventually dug into the source code and found the string constant I was looking for in the eiffel-semantics repository (had I discovered https://eiffel-community.github.io/eiffel-remrem-generate/serviceUsage.html things would've been easier). There's an opportunity to improve the API discoverability by introducing a /message_protocols endpoint that simply returns the available message protocols, i.e. something like this:

msgServices.stream()
    .map(MsgService::getServiceName)
    .sorted()
    .collect(Collectors.toList())

Motivation

The suggested new endpoint would make it easier to use the API based only on the Swagger definition, especially for deployments that aren't solely using the default message service implementation. The implementation and maintenance cost would be very low.

[SantoshNC68]

When you try out the versions it will return the message protocols available. Have you tried the GET /versions endpoint.

[magnusbaeck]

There's no mention of "eiffelsemantics" here:

$ curl -sS localhost:8080/versions | jq .
{
  "serviceVersion": {
    "version": "2.0.8"
  },
  "endpointVersions": {
    "semanticsVersion": "2.0.6"
  }
}

[e-pettersson-ericsson]

Indeed, the documentation about the existing endpoint /versions states that it returns the version of the remrem service as well as which protocols are loaded, but the actual response given back is not at all intuitive. First of all, the protocol name is changed in the json response so the users have no idea what the "semanticsVersion" means. I also wonder what is the "endpointVersions" supposed to represent?

Is it possible to change the response in the existing endpoint (this will require an API uplift) or better to simply add the new endpoint like @magnusbaeck suggested?

[e-backmark-ericsson]

Should there be two separate endpoints instead? One for the REMReM Generate code itself, and another one for the protocol version(s) supported. The name of the protocol version there should be the same as used in the other generate endpoints. And it would be good to include the Edition name as well as its version (if there is an edition for it)

[magnusbaeck]

Sure, a /messageprotocols endpoint would make sense. Perhaps something like this?

[
  {
    "name": "eiffelsemantics",
    "eiffel_edition": "paris"
  }
]

[zburswa]

Had some discussions regarding the above suggested endpoint. I will implement this new end endpoint in REMReM generate.

[magnusbaeck]

This issue is open but the linked PR was merged a year ago. Should the issue be closed?

[e-backmark-ericsson]

Yes. It should be closed.