add the catalog endpoint

[nimakaviani]

• make the service configurable through the service file
• parse configuration into brokerapi.Service
• refactor Config and service api endpoints

finishes #5

[cfdreddbot]

Hey nimakaviani!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA.

[jberkhahn]

We think it would make more sense to have the info describing the services be in separate files, similar to how the old ruby broker worked. It would make it much easier to maintain that functionality, both when using the broker stand alone and with the bosh-release. Maybe have the config contain the location of a directory to load service jsons from.

[nimakaviani]

@jberkhahn fair point. The only reason I initially collapsed them into one file was to avoid having to introduce flags. Cause multiple input args without using a proper cli flag library is bad practice. But I agree. separating those would be better.

[jberkhahn]

What do we need flags for? You could just make a field in the config that is the location of a dir to load the service files from.

[nimakaviani]

oh I was thinking ./broker -config [path] -service [path]

relative / absolute path in the config file is kinda ugly.

[swetharepakula]

How would the -service flag work with multiple services? I like the idea of a directory or just providing a list of files. Unless the flag was to signal the array of filenames.

[nimakaviani]

generally you can use flags to pass a slice through. like the following:

./broker -config [path] -service [path1] -service [path2]

e.g., similar to how ops files are passed through to a bosh cli.

If a directory, it should be internal and we should just read everything in it, rather than making it part of the config but that is implicit logic which is hard to reason about. In case of the broker bosh release, those yml files get passed into the deployment as bosh opsfiles .

[nimakaviani]

closed in favor of #23