I am not sure to properly understand your second paragraph. Here's an answer: URLON supports both "stringify" and "parse" operations. So you can go both ways.
You can even do fun things like URLON -> Javascript Object -> JSON if you want to. The fact that it is 100% compatible with JSON is a great benefit.
As for my use, the URLON is in the hash part of the URL (after the #) so everything in running in the client. This is useful to give URLs that hold the current state of the page.
If you need to store page state RESTfully, I would suggest you create a page state resource and PUT your state there. If you need a page's state, ask for it by name. This also has the benefit of keeping URLs shorter and cleaner.
Create a new /items/pageState URI that accepts POST, PUT, and GET requests.
POST to /items/pageState to get a handle - this could be a randomly generated small sequence of characters. A response will contain a Location: header with a URL: /items/pageState/aA1 (the aA1 is just an example for this description - each user would get an unused sequence of characters)
Anytime the user changes the state of the page, PUT the page number, sorted-column, and reverse fields to /items/pageState/aA1.
Now, the url of the items page to http://db.mmo-champion.com/items/?pageState=aA1. When that page loads, the JS will make an Ajax GET request to /items/pageState/aA1 to fetch the state of the page, and re-render it appropriately.
If you're concerned about speed, well, don't be. Add support for eTags on /items/pageState, and while the state is unchanged, that data will be fetched from browser cache instead of the network.
One state per user is not what I want. If the user sorts in one way, give a link, then sorts in another way and put a link back. I want both links to be differents.
Also, your solution adds a lot of extra server calls. The goal of client-side sorting & pagination is to avoid those. I don't want to get them back just for the sake of being RESTful.
My solution does not have to add a lot of extra server calls - it all depends on the caching strategy you choose. For example, if you use maxAge, you would only be adding one extra request per new state created, or per new fetch; all subsequent fetches for the same state would automatically pull from the browser cache.
To satisfy the linking requirement, I would redesign my solution to just POST the state to /items/pageState, and get back a URI that represents only that state (which can be shared across all users). Combine this with the maxAge, and yes, you would have to make more requests, but the extra overhead would still be way less significant than adding a link to an image on every page (especially in terms of bandwidth)
But, chacun à son goût! Everyone prefers their own tradeoffs :)
You have to store state in the URL. Otherwise how can people link to particular "states" within your application? There would be no way to address them without being part of the URL.
I outlined a way to do this nearby. :) State can be stored using query parameters. If you have enough state that URIs become unwieldy, then the method I suggested nearby would work very well.
You can even do fun things like URLON -> Javascript Object -> JSON if you want to. The fact that it is 100% compatible with JSON is a great benefit.
As for my use, the URLON is in the hash part of the URL (after the #) so everything in running in the client. This is useful to give URLs that hold the current state of the page.