Unlike /etc/services (which is per se a conffile, and as such depends on OS package updates to be up-to-date), this service regularly fetches updates from the IANA database, so as to be constantly up-to-date with ports being registered for well-known local services.
A typical example is tcp/2375 (the default port for the Docker daemon REST API), which is registered in the IANA database, but at this time absent from /etc/services.
This service also allows to mix various databases. For example, the Nmap Services [1] (which also tries to track well-known ports for trojans, worms and the like) is supported.
Well, the point of this microservice is to determine which service is supposed to listen on which given port (or vice-versa).
Sure, /etc/services can be edited locally, but that means the local administrator already knows such service-port-protocol mapping. And a conflict may occur later on at any OS package update.
Also, this microservice is intended to be queried from anywhere, especially from restricted systems (e.g., from Android devices) where it is not possible to access such admin configuration files.
Actually, this was developed out of a real need in one of the Android apps I'm working on: DD-WRT Companion
A typical example is tcp/2375 (the default port for the Docker daemon REST API), which is registered in the IANA database, but at this time absent from /etc/services.
This service also allows to mix various databases. For example, the Nmap Services [1] (which also tries to track well-known ports for trojans, worms and the like) is supported.
[1] https://nmap.org/book/nmap-services.html