Hacker News new | past | comments | ask | show | jobs | submit login

I'm not sure to understand what you mean. Could you tell me how I would implement that on a concrete example:

http://db.mmo-champion.com/items/#table__search_results_item...

I want to store: page number, sorted-column, reverse.




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.


Ah, new constraints on the problem! :) Love it!

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 :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: