Sean P. DeNigris wrote:
> I was surprised not to find any threads about this in the mailing list. What
> is the best way to provide a REST API to an all-Amber web app?
>
> At first I was thinking of using HTML5's pushState like:
> "Ignore url path when serving"
> amber serve --fallback-page index.html
>
> "Query url path to initialize my Amber app"
> window location pathname tokenize: '/'...
>
> "Change the browser URL on Amber state change"
> window history pushState: 'object or string' named: 'Title' at: '/new-url'
>
> ... but it looks like it's only available starting with IE10.
>
> So I guess hash hacking? Something like:
>
http://127.0.0.1:4000/#1-2-3> (window location hash trimLeft: '#') tokenize: '-'
>
> Or is there something better that I'm missing?
I was confused a bit since this mail is about web page routing, not
about REST APIs per se. I will assume the problem you are trying to
solve is the single-page in-app routing.
The --fallback is indeed create especially for such single-page apps
which use HTML5 pushState-based in-app routing and thus can use full
path to encode the state. Yes, it's true that support in across the
browsers is not yet ideal and it's hard to polyfill this functionality,
so #!/path/to/state fallbacks are often used.
The way how it is done is to use some library specifically designed to
solve in-app-routing (director, leviroutes, ...) and just use it. Those
libraries can use either full HTML5 path or hashbang one, and achieve
same goal using either of them. Existence of these libraries is also
probably the reason why it wasn't especially mentioned in relation to
Amber - Amber hasn't its own idiomatic way to solve in-app-routing - you
choose which lib to use and just use it.
Herby
> -----
> Cheers,
> Sean
--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[hidden email].
For more options, visit
https://groups.google.com/d/optout.
Locked
