3 ms·
> URLs aren't meant to be used this way I disagree, URLs are supposed to point to a resource - in this case the resource is the client state of the app (aka "d
by AndrewStephens 4y ago
> URLs aren't meant to be used this way
I disagree, URLs are supposed to point to a resource - in this case the resource is the client state of the app (aka "deep linking"). It is a useful approach.
Of course, it can easily be misused.
- hot_gril 4y agoThe suggestion was to put your entire client state into it, which is probably more than just the resource location (aka deep link).
- naasking 4y agoThere is no such thing as "client state" separate from the notion of resource under REST. The URL is meaningful only to a server. If a server can encode data in the URL so it doesn't need to persist it, that's perfectly fine, so long as the URL conforms to all expectations of resources, ie. caching directives, lifetime, etc.
- hot_gril 4y agoModern web apps often use the URL in ways that only matter to the client and can be edited client-side without issuing another request to the server, unless you reload manually, in which case everything is reset except the URL state. This doesn't violate REST principles. Some of that makes sense to put in the URL so users can return to past state, some is very temporary and wouldn't make sense at all to persist across a reload/back. For example, you may track the scroll position for the purpose of loading more content when the user reaches the bottom of a feed, but you don't want to persist that across reloads. And the user may click on some content and anchor the view to it, which you do persist in the URL for the purpose of history or sharing.
- naasking 4y agoSure, and all of that belongs in the fragment of the URL which is not sent to the server but is specifically reserved for client-side resources.