UI: Encode prediction parameters in the URL

cuspaceflight / tawhiri

CUSF Landing Prediction Software

http://predict.habhub.org/

GNU General Public License v3.0

17 stars 37 forks source link

UI: Encode prediction parameters in the URL #103

Closed danielrichman closed 7 years ago

danielrichman commented 9 years ago

The main requirement is for people to be able to share predictions with each other by copying a URL.

The solution we've been planning is

Prediction parameters encoded into URLs with HTML5 history storing and loading
No persistent state on the server. If it becomes necessary, a caching layer in front of the API can avoid re-runs of a popular prediction.
Wishlist/maybe: shortlink server to produce small ids for sharing

rjw57 commented 9 years ago

Presumably it's sufficient to stuff something magic in the fragment? I.e. http://predictor.example.com/#p=[SomeMagicEncodedString]. Using a URL-safe Base64 equivalent, one can probably stuff quite a lot in there.

danielrichman commented 9 years ago

Yeah, that's the idea.

I get the impression (to a certain extent) that putting things in fragments is old and busted, and html5 history is the new hotness.

It is unclear to me whether it would actually be appropriate to do that here; we'd end up with URLs like predict.cusf.co.uk/path/b64-data. Maaaybe /time/lat/lon/b64-other-parameters. We'd have to make the webserver return index.html for all such URLs.

The latter requires (more) support from the browser. In either case it would be nice to use the relevant browser features to ensure the back button works.

rjw57 commented 9 years ago

You can still do fragments + HTML5 history (IIRC) although HTML5 history also lets you do magic with the full URL after the page is loaded. That being said, fragment tricks are appropriate when there isn't a real URL for a particular prediction. Switching over to a real URL (e.g. http://server/predictions/:id) has some advantages. One can statically "seed" the UI on a GET by embedding the result in the UI and use that URL as in the HTML5 history. In other words, web server tricks are not needed if we actually use real URLS.

Having .../predictions/:id work requires we have some server-side state stored, though whereas doing something like "serve UI with prediction pre-loaded" doesn't.

rjw57 commented 9 years ago

To clarify: we already have a GET route for a URL which encodes everything we need to know about a prediction; this is the v1 API. If we just serve a UI with a pre-loaded prediction for a GET request when Accept-Encoding: application/json isn't set then we can re-use the URLs directly in the HTML5 history API.

adamgreig commented 7 years ago

Closed while we rethink the UI.