Client-side URLs and routing
Bookmarkable URL holding state
Client URLs need to be able to hold state—that is, you can put them in the clipboard and open in a new browser window and get exactly the same view. They key is that the client needs to be able to render a particular layout against a data. There are multiple parts to doing this:
- url fragment:
/#/marks that it is all client side - client view: in a client there is the client ‘view’ (component) to be rendered
- pivot point:
/a/is just a short marker - api resource: the resource that is being loaded from the API. Also, for readability the API resource is likely to have a reduced form that removes the base entry. For example, the entry point of the API is
https://api.example.com/and we are loadinghttps://api.example.com/todo/5then on the bookmarkable URL we will maptodo/5back to the original url. - client-side filtering: can be added also as a query (this is used on the todo app)
Note: this approach is not HTML5 because it does not return to the server for server-side rendering of the page. This means that the entire URL is the ‘state’ and is only known to the client.
Some general guidelines
- the starting url is in the HTML page as a link rel (eg
<link rel="api" href="http://localhost:5000/"/>in<head>) - never do URL construction, but URL mapping is useful for shortening
- mapping will need to be able to move back and forth between client and API forms
Unlock the next chapter
A prerequisite of a bookmarkable URL holding state is?
A single-page application with a single entry point
A known starting URI
The ability to rewrite and decode URIs
All of the above
Skip