Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve URL routing of web page content versus API routing #146

Closed
GUI opened this issue Nov 6, 2014 · 1 comment
Closed

Improve URL routing of web page content versus API routing #146

GUI opened this issue Nov 6, 2014 · 1 comment

Comments

@GUI
Copy link
Member

GUI commented Nov 6, 2014

We need to make 2 semi-related changes to how we route APIs versus the static web page content (documentation, the signup form, etc):

  1. Remove the need to explicitly white-list the URL prefix paths that get routed to the static web page site. Since we don't have a particularly easy way to update this whitelist, it makes it cumbersome and non-intuitive when you want to add new areas to the website (Adding /developer page #143 is a good example. Also see resolve /community page  #89 and Make 404 not found responses consistent #99).
    • We can easily achieve this by flipping our whitelist logic around: Since we do know all the URL prefixes for the APIs we're routing to, and those are all managed via the web admin, that should be the whitelist. Then the fallback if it isn't in the list of URL prefixes for known APIs should be the static web page content.
  2. Allow defining multiple different web page servers to route to based on the domain name. While we support routing APIs based on domain name, we also need to be able to route this other web page content (docs, etc) based on hostname. This becomes more critical to support certain types of hosting arrangements if we want the agencies to be able to keep their own domain (for example, we'll need this to transition developer.nrel.gov over since our API and docs are on one domain, so it's not as simple as aliasing a dedicated hostname for APIs like we've done in in the past. I suspect we'll also need this for some of the other recent agencies we've been talking to for similar reasons).
@GUI
Copy link
Member Author

GUI commented Mar 30, 2015

These routing changes have been rolled out to production. This should greatly simplify introducing new website content (pages should just show up, rather than needing explicit configuration), and it also adds new capabilities to the admin UI for managing the website content for different domains (which we'll need for our plans to transition developer.nrel.gov over).

Since this changes some low-level routing details, I've done lots of sanity checks to ensure that all existing API endpoints are continuing to route correctly (I added a quick one-off script to replay requests based on previously seen URLs in the log files). Everything appears to check out.

Implemented in NREL/api-umbrella-router#6 and NREL/api-umbrella-web#10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants