Enable reachable URLs for all 2018 API services

[MikeTheCanuck]

All 2017 API services are reachable as Swagger-UI-enabled interactive applications through these URLs:

• Budget http://service.civicpdx.org/budget/
• Emergency Response http://service.civicpdx.org/emergency/
• Homelessness http://service.civicpdx.org/homeless/
• Housing http://service.civicpdx.org/housing/
• Transportation http://service.civicpdx.org/transport/

All 2018 API services will be similarly reachable. Based on the APIs we know about so far, here is how they should be reachable:

• Disaster Resilience http://service.civicpdx.org/disaster-resilience
• Housing Affordability http://service.civicpdx.org/housing-affordability
• Local Elections http://service.civicpdx.org/local-elections
• Neighborhood Development http://service.civicpdx.org/neighborhood-development
• Transportation Systems http://service.civicpdx.org/transportation-systems

[iant01]

Since we are partitioning the 2018 API's from the 2017 API's we probably should do the same with the swagger access and put them in the same domain (currently staging-2018.civicpdx.org) something like service.staging-2018.civicpdx.org/transportation-systems just to be consistent.

[iant01]

@MikeTheCanuck said: I like consistency, but I'm personally less worried about people outside Hack Oregon discovering these APIs prematurely - I infer that the "staging-2018" naming was meant to reduce chances of outsiders stumbling on the 2018 dataviz apps prematurely. We pre-published the service.civicpdx.org Swagger apps last year a month before Demo day and had no problems.

[iant01]

Since we are moving in the direction of domains/sub-domains, it would help keep us out of trouble with load balancer listener rules and possible collisions between last years API's and this years API's Last years housing API and this years housing-affordability API would both have the same path to the swagger page service.civicpdx.org/housing

[MikeTheCanuck]

With clear unique naming there should be no chance of collisions.

Help me understand how /housing and /housing-affordability would end up with the same URL http://service.civicpdx.org/housing and not as I've specified explicitly above.

[iant01]

Right now the service end point for the 2017 housing API is /housing. As currently implemented in the civic-2018 service landing page the 2018 housing-affordability service end point is /housing as well. Yes, this is something easily changed by code, building a new civic-2018 service container but it highlights the problem of sharing one sub-domain for the API/swagger access for multiple sets of API's (ie. piling them all in service.civicpdx.org when the front-ends for are in civicpdx.org and right now the font-ends for 2018 are/will be in staging-2018.civicpdx.org. (probably will move to 2018.civicpdx.org later in project) Keeping groups services (years, etc.) separated eliminates the possibility collision and ordering problems in the listener rules between groups of services (API's) and reduced the order issues within a group of services. (technically the 2017 services are in civicpdx.org but not explicitly at the listener rule level, just the route53 (DNS) level which has been helping to cause the issues that have occurred (last year and so far this year, the idea of sub-domain'ing was implemented only at the DNS lev el and not the load balancer listener rule level as well)

[iant01]

Issue #109 depends on this issue

[MikeTheCanuck]

I still don't understand this "civic-2018 service landing page" you speak of where two Django apps will collide. Are you talking about http://service.civicpdx.org or http://staging-2018.civicpdx.org? Be specific with what URL you mean, or where in our source code you see the collision. I still believe that /housing and /housing-affordability will live as separate Django apps on separate API containers.

I agree that there's possible confusion in the naming of the URLs for the separate FE React apps http://staging-2018.civicpdx.org/housing and http://2017.civicpdx.org/housing, but there's still no technical problem there (though a human problem in my mind).

[MikeTheCanuck]

As of PR 30 this can be safely closed - routing works for the Disaster-Resilience container (traffic gets through ALB to the gunicorn server and answered by Django).