[JAVA] Pricewatch-achtige permalinks

[qrazi]

Vooraf:

Ik weet niet 100% zeker of dit juist forum is, maar lijkt mij het meest passende. Ik heb de search van GoT en Google gebruikt.


Dan nu mijn vraag. Voor een webshop moet ik het filter aanpassen. Net als in de Pricewatch kunt je met het filter de weergegeven producten beperken aan de hand van selecties. Nu werkt dit via ajax middels POST aanvragen.

De huidige oplossing moet twee aanpassingen krijgen:
- ondersteuning voor "back" etc
- permalink-mogelijkheid

Puur het eerste punt kan ik nog wel oplossingen bedenken, maar voor het tweede punt loop ik een beetje vast. Permalink gaat per definitie per GET. Maar als je erg veel selecties zet, wordt dat een hele lange URL. En ik geloof dat best practice is om GET-requests maximaal 255 tekens te houden.

Nu heeft de Pricewatch, en ook Prijsvergelijker van Hardware.info, een permalink-oplossing die met een hashcode lijkt te werken (bijv. http://tweakers.net/price...SS1JTggtRkqLFGFkADjJViawE).

Het grote voordeel hiervan lijkt mij dat de lengte van de URL niet evenredig toeneemt met het aantal geplaatste selecties. (maar misschien kijk ik hier helemaal verkeerd tegenaan, en is dit geen valide reden)

Mijn grootste probleem is nu hoe je in een JAVA backend van een hashcode naar een bepaalde selectie van de VIEW gaat. Want een hashcode kun je niet decrypten, en een echte encryptie neemt wel ongeveer evenredig toe qua lengte. Iemand die mij een duw de goede richting op wil geven?

[alex3305]

Zelf heb ik ook ooit zoiets gemaakt en dat had ik zo gedaan:

1. Parameters in JSON meegeven.
2. JSON naar Base64 omzetten
3. Base64 met gzip verkleinen
4. Gzip compressie meegeven aan de url.

Het voordeel van deze methode vond ik dat het ontzettend gemakkelijk aan beide kanten te decoden en encoden is, waarnaast er ook nauwelijks snelheidsverlies in zit. Gemiddeld werden bij mij JSON strings van 400 karakters verkleind naar een goede 200 tot 250 karakters na de gzip. En hoe meer tekens er in een string stonden, hoe effectiever het uiteindelijk was.

[creator1988]

Je kan ook gewoon de hash van de URL (achter de #) hiervoor gebruiken als je toch al alles client-side afhandelt. Gebruiken wij om op funda de grote kaart qua state bij te houden:

En permalinks werken ook prima: http://www.funda.nl/koop/...opp/2+kamers/appartement/

N.B. De max van de URL + hash is ~ 2083 chars (in IE). Dus daar zit je nog lang niet aan.

Nog even wat info. Wij gebruiken een centraal object dat een 'zoekopdracht' heet. Dit object kent een lijstje met 'criteria', bijvoorbeeld: 'KoopprijsVan' met waarde '100000', of 'IndTuin' met waarde 'true'. Dit is fijn, want makkelijk te serializen naar een URL waarde. Bijv: kpv=100000&tuin=true. Zo kan je dit wel complex maken zonder dat je heel veel chars nodig hebt. Wij hebben hier dan ook een 'friendly' URL handler die je eraan kan hangen, en die vertaalt de zoekopdracht naar /100000+/tuin/.

In de lijst links (de filters) kunnen we heel makkelijk permalinks genereren. Namelijk ongeveer zo:

C#:

// bijv.: je POST vanuit javascript de hash naar de controller
var zo = FriendlyUrlHandler.Fill("/amsterdam/oude-pijp/tuin/");

// die doet nu
// bepaal nieuwe permalink voor 'met sauna'
var metSauna = zo.Clone();
metSauna.AddCriterium("IndSauna", true);
var nieuwePermaUrl = FriendlyUrlGenerator.ToUrl(metSauna);

// tah dah

[ Voor 84% gewijzigd door creator1988 op 06-09-2011 12:57 ]

[qrazi]

# van de url gebruiken voor state was me duidelijk. Dat is denk ik voor mij ook geen probleem. Het ging me alleen meer om de lengte ervan.

Ik kom best practices tegen van 255 tekens voor de URL. Met een zeer uitgebreide selectie kunt je daar makkelijk overeen. Ik nam een beetje aan dat dat de reden is voor de Pricewatch en Prijsvergelijker om een hashcode-achtige oplossing te gebruiken.

Alleen kan ik dus niet bedenk hoe je zoiets in de backend opvangt. Als je hashcodes wilt vergelijken, moet je van tevoren alle mogelijke selecties een keertje bij langs, en de bijbehorende hashcodes ergens bewaren.

Maar misschien zit ik er helemaal naast en is het '255-tekens' helemaal geen limiet waar ik rekening mee moet houden... Als dat trouwens zo, vraag ik me af wat de reden is voor de urlopbouw in Pricewatch en Prijsvergelijker.

Suggestie voor Base64 + Gzip; hoe gzip je in de client? Moet de browser daar ondersteuning voor hebben?

Zie net de edit van Creator88:
Ok, 255-tekens is dus non-argument. Dan heb ik in feite ook geen probleem... Maar dus nog wel nieuwsgierig naar waarom zowel Pricewatch als Productvergelijkers hashcode-actige URL gebruiken. Wat is het voordeel daarvan?

[ Voor 12% gewijzigd door qrazi op 06-09-2011 12:58 ]

[creator1988]

qrazi schreef op dinsdag 06 september 2011 @ 12:55:
# van de url gebruiken voor state was me duidelijk. Dat is denk ik voor mij ook geen probleem. Het ging me alleen meer om de lengte ervan.

Ik kom best practices tegen van 255 tekens voor de URL. Met een zeer uitgebreide selectie kunt je daar makkelijk overeen. Ik nam een beetje aan dat dat de reden is voor de Pricewatch en Prijsvergelijker om een hashcode-achtige oplossing te gebruiken.

Alleen kan ik dus niet bedenk hoe je zoiets in de backend opvangt. Als je hashcodes wilt vergelijken, moet je van tevoren alle mogelijke selecties een keertje bij langs, en de bijbehorende hashcodes ergens bewaren.

Maar misschien zit ik er helemaal naast en is het '255-tekens' helemaal geen limiet waar ik rekening mee moet houden... Als dat trouwens zo, vraag ik me af wat de reden is voor de urlopbouw in Pricewatch en Prijsvergelijker.

Suggestie voor Base64 + Gzip; hoe gzip je in de client? Moet de browser daar ondersteuning voor hebben?

Zie mijn edit trouwens.

[RobIII]

qrazi schreef op dinsdag 06 september 2011 @ 12:55:
Suggestie voor Base64 + Gzip; hoe gzip je in de client? Moet de browser daar ondersteuning voor hebben?

Natuurlijk niet; het zippen en un-zippen gebeurt allemaal server-side. Als je gewoon base64 die data passed heeft je client er niets mee van doen.

Als je echt in zit over de lengte van de URL (en zoals je gelezen hebt hoeft dat, voorlopig, nog niet ) kun je natuurlijk ook gewoon de selectie in een sessie, of beter, de DB mikken en, in het geval van de DB, dan enkel het "id" van de selectie doorgeven bijvoorbeeld. Dan kun je tot terabytes ( ) aan selectiecriteria opslaan en volstaan door een &selectionid=297382 door te geven

[ Voor 35% gewijzigd door RobIII op 06-09-2011 13:18 ]

[qrazi]

RobIII schreef op dinsdag 06 september 2011 @ 13:16:
[...]

Natuurlijk niet; het zippen en un-zippen gebeurt allemaal server-side. Als je gewoon base64 die data passed heeft je client er niets mee van doen.

Als je echt in zit over de lengte van de URL (en zoals je gelezen hebt hoeft dat, voorlopig, nog niet ) kun je natuurlijk ook gewoon de selectie in een sessie, of beter, de DB mikken en, in het geval van de DB, dan enkel het "id" van de selectie doorgeven bijvoorbeeld. Dan kun je tot terabytes ( ) aan selectiecriteria opslaan en volstaan door een &selectionid=297382 door te geven

Duidelijk. Maar gezien de rest van de situatie schets is Base64 encoding sowieso eigenlijk overbodig...

Die tweede paragraaf, dat heb ik ook overwogen. Lengte is nu dus geen bezwaar meer. Maar dit is wat de PW doet? Waarom?

[ Voor 40% gewijzigd door qrazi op 06-09-2011 13:20 . Reden: edit-reactie op edit-reactie.. ]

[RobIII]

Zie overigens ook Pricewatch filter URL, welke techniek?

qrazi schreef op dinsdag 06 september 2011 @ 13:18:
[...]


Duidelijk. Maar gezien de rest van de situatie schets is Base64 encoding sowieso eigenlijk overbodig...

Als je maar zorgt dat je dan de "gzip data" fatsoenlijk escaped hoeft dat niet; een Base64 representatie is misschien wel iets meer overhead maar wel dan weet je iig dan je altijd alleen maar een beperkte set tekens in de URL hebt. Mocht iemand zo'n url willen plakken in (bijv.) een email of forum of whatever dan is er een vette kans dat er (bijv.) geen automatische linkjes van worden gemaakt omdat er een zooi vage tekens in staan:

code:

http://mysite.nl/search?selection=%9C%7E%14%7C%A0z%E6%94%1E8%1C%F7%A3%23%1C%2F%1D%E8%008%E9%FA%FB%D2%7C%A4%E3%A5.G%A7%CBFFFG%1D%A8%012%A4%E7%18%C7jPG%5Cs%E9Fy%E5y%ED%40%3E%DF5%00%27%CA%07

.
vs:

code:

http://mysite.nl/search?selection=nH4UfKB65pQeOBz3oyMcLx3oADjp+vvSfKTjpS5Hp8tGRkZHHagBMqTnGMdqUEdcc+lGeeV57UA+3zUAJ8oH

Beiden bevatten dezelfde "binary data" (die ik gewoon uit een willekeurige file getrokken heb). Wegens percent encoding heb je toch al overhead; die Base64 maakt 't 'm dan ook niet meer Sterker: de percent-encoding is waarschijnlijk "groter" zoals je hier al ziet.

Feit is dat een boel software wegens "matige regexen" de eerste URL vaak niet of half of verkeerd zullen interpreteren en dus verkeerd "linken" / "highlighten" / ... Bij de tweede is die kans natuurlijk ook aanwezig maar kleiner.

[ Voor 137% gewijzigd door RobIII op 06-09-2011 13:30 ]

[qrazi]

RobIII schreef op dinsdag 06 september 2011 @ 13:19:
Zie overigens ook Pricewatch filter URL, welke techniek?


[...]

Als je maar zorgt dat je dan de "gzip data" fatsoenlijk escaped hoeft dat niet; een Base64 representatie is misschien wel iets meer overhead maar wel dan weet je iig dan je altijd alleen maar een beperkte set tekens in de URL hebt. Mocht iemand zo'n url willen plakken in (bijv.) een email of forum of whatever dan is er een vette kans dat er (bijv.) geen automatische linkjes van worden gemaakt omdat er een zooi vage tekens in staan.

Bedankt voor de link, raar dat ik die niet zelf gevonden had (zucht..).

Ik denk eigenlijk dat ik zo helemaal geholpen ben!

[Verwijderd]

alex3305 schreef op dinsdag 06 september 2011 @ 12:37:
Zelf heb ik ook ooit zoiets gemaakt en dat had ik zo gedaan:

1. Parameters in JSON meegeven.
2. JSON naar Base64 omzetten
3. Base64 met gzip verkleinen
4. Gzip compressie meegeven aan de url.

Het voordeel van deze methode vond ik dat het ontzettend gemakkelijk aan beide kanten te decoden en encoden is, waarnaast er ook nauwelijks snelheidsverlies in zit. Gemiddeld werden bij mij JSON strings van 400 karakters verkleind naar een goede 200 tot 250 karakters na de gzip. En hoe meer tekens er in een string stonden, hoe effectiever het uiteindelijk was.

Ik vind het raar dat je het éérst base64 encode en dan gzipt. Dan krijg je toch allemaal binaire data in je url? Kun je het niet beter andersom doen? Je gegzipte data base64 encoden?

[MSalters]

Het grootste probleem lijkt me dat je die filters om te beginnen niet effectief representeert. Een URL van 255 karakters kan ongeveer 230 karakters effectief bevatten. Dat zijn 26387242987402076860897009074092000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 verschillende URLs. Hoeveel filter combinaties heb je?