Open AlexChiquito opened 7 months ago
Link to reviewed document: eu.arrowhead.service-discovery-http-json.yml.
"The service allows for application systems..." and not for consumers.
camelCase
or only kebab-case
."echo" operation should not be part of this service, but a different "monitor" service.
serviceInstanceIDs
: In the management service the related field was named as serviceId. The same should be used everywhere.serviceID
: Why the provider should specify the service instance id? How it knows what is unique? It should be generated based on the provider name, service definition and version by Service Registry and returned as a response.DeregisterExpression and QueryExpression
What are these and where they are used?
NOTE:
@AlexChiquito @emanuelpalm @PerOlofsson-Sinetiq Could you please provide Sinetiq's feedback before the next RoadMap (05.02) in order to being able to discuss it there? As you know, last time the 14th of May (before AIMS 5.0 GA) was agreed to target the specification being finalized, so we don't have so much time.
Hello, I will summarize my comments here, some of which overlaps with the above and other things are new. They can be divided into three areas, scope of a service registration record, relation between instances and types, and finally good API design.
providerId
property to not encourage misuse of the system concept. The mapping of services to systems from a governance perspective needs to happen in another service.In summary, the record should then look something in the line with the following. Note that I did not make any changes to the property naming as suggested by AITIA above, I don't have anything against this. It was just to limit the changes for the sake of the discussion.
{
"serviceID": "string",
"serviceType": "eu.arrowhead.authorization-http-json:5.0.0",
"addresses": {
"additionalProp1": "tcp4:192.168.0.7:45326",
"additionalProp2": "tcp4:192.168.0.7:45326",
"additionalProp3": "tcp4:192.168.0.7:45326"
},
"metadata": {
"basePath": "v2"
},
"timeToLive": "2d12h"
}
GET /services/{service-id}
endpoint gets replaced by GET /services({service-type}/instances/{service-id}
DELETE /services/{service-id}
endpoint gets replaced by DELETE /services({service-type}/instances/{service-id}
GET /services({service-type}/instances
, is added that lists all instances for a single service type.expiresAt
would be better than a timeToLive
.Dear @DavidRutqvist
Regarding to the service-type
:
service-type
in your IDD is basically the serviceDefinition
from v4.x, plus some interface information, (plus you suggests also the version), and you don't have a separate field for the service definition. What is the point of this merging? How to look up then for a service definition without any interface information?Regarding to the serviceId
:
Regarding to your "Good API Design" points: we fully agree
Please also give feedback on the issue #87, because it belongs to the same domain and there are also open questions/suggestions. The question of interface representation would be the most important one.
Sinteiq, can you comment on this.
For now we should continue to use the latex documentation instead of languages specific to for example HTTP REST implementations.
The service discovery record may need some modification due to the extendable service interface of sth SysMonitor and the SD_Monitoring service.
In this Issue we will collect the comments about the service-discovery interface definition.