Change server URL prior to release and/or ensure client can handle redirects

[jasonrudolph]

The real-time package currently accesses the real-time server at
https://atom-tachyon.herokuapp.com. We'll likely want to eventually use a github.com or atom.io URL instead of a Heroku URL. Prior to the public beta release, I think we should do one or both of the following:

• Replace https://atom-tachyon.herokuapp.com with a github.com or atom.io URL (e.g., https://live.github.com) [1]
• Ensure that the real-time client handles redirects, so that we have the freedom to update https://atom-tachyon.herokuapp.com to redirect to a different domain at any point in the future

---

[1] ⚠️ Choosing the "right" domain could be quite the bikeshedding exercise 😬

[jasonrudolph]

Ensure that the real-time client handles redirects, so that we have the freedom to update https://atom-tachyon.herokuapp.com to redirect to a different domain at any point in the future

With our current code, redirects alone could meet our needs. We'd need to update the server to redirect with a 301 status code for HEAD and GET requests, and a 307 status code for all other request verbs (e.g., POST). If we follow that approach, Electron will automatically follow the redirects. 👌

---

Note: We can't simply use a 301 redirect for all requests. When Electron (and other common HTTP clients) receive a 301 redirect, they use a GET request to follow the redirect. That's fine if the original request was a GET, but it's problematic if the original request was a POST, PATCH, DELETE, etc. In response to a 307, Electron uses the originally-specified HTTP verb to follow the redirect. 😅

FWIW, this is the same approach we used to implement redirects for renamed repositories in the GitHub API. https://github.com/github/github/pull/38672#issuecomment-75312884 😀

[nathansobo]

Okay, good to know. It might be nice to get a URL without herokuapp.com in it prior to release though so maybe let's leave this open.

[jasonrudolph]

It might be nice to get a URL without herokuapp.com in it prior to release though...

Totally. We can set up an atom.io subdomain easily. Agreeing on a github.com subdomain would likely require more discussion.

I'll toss up a few options to kickstart the discussion:

• api.realtime.atom.io
• api.real-time.atom.io
• tachyon.atom.io
• real-time-api.atom.io

Are any of those particularly appealing? Do any other ideas come to mind?

[as-cii]

How about realtime-api.atom.io? I don't dig the 4th-level subdomain variant, and tachyon feels somewhat obscure (and asymmetric compared to our potential mini-site URL, realtime.atom.io).

[jasonrudolph]

@as-cii: Can we talk you into api.tachyon.atom.io?

/cc @nathansobo
/cc https://github.slack.com/archives/C65B6TS0K/p1506461529000042

[as-cii]

I was assuming we wanted to stick with real-time, but as long as we re-brand the entire ecosystem as tachyon I am cool with api.tachyon.atom.io. 👍

[jasonrudolph]

I've updated https://github.com/github/dns/pull/752 to use api.tachyon.atom.io.