Gli URL SERP di ricerca sito non utilizzano parametri di query, ma utilizzano la struttura di directory? Cosa succede con quello?

1

Lavoro con un sito che utilizza una funzione di ricerca del sito per i suoi utenti. Prima di lavorare su questo sito, mi sarei aspettato dei risultati in stile GET con parametri come "/ search? Q = entrepreneur" o risultati in stile POST senza un parametro come "/careersection/10000/jobsearch.ftl"

Questo sito funziona anche in un terzo modo che non capisco. I suoi percorsi di pagina SERP sono simili a "/ ListJobs / ByKeyword / robot-dog-farmer /"

Il termine non è oscurato come sarebbe dopo una ricerca POST. Né è rappresentato in un parametro come lo sarebbe dopo una ricerca GET. Quindi, cosa sta succedendo? Sembra che ci sia una struttura di directory che viene creata al volo in base all'input dell'utente.

    
posta Ryan Keeler 11.07.2016 - 16:43
fonte

1 risposta

0

Può essere uno dei seguenti:

  • Archiviazione nel database e associazione dei percorsi URL alle query del database
  • Archiviazione su un file e associazione dei percorsi URL ai nomi di file
  • Archiviazione in memoria e mappatura dei percorsi URL alle strutture dati

In termini di design dell'URL, è senza stato:

Imagine a shop where rather than being self-service, there is a shopkeeper who upon being asked, goes and fetches the items you want and rings them up on the till. Now if we were to model that as our online shop we'd see that the client no longer has a basket as part of their state, the basket is part of the shop.

So how would this work? Looking at the interactions between the client and the server, it might look something like this:

Client

Show me your products.

Server

Here's a list of all the products you can buy at this shop.

Client

Good, okay, I'd like to buy 1 of http://example.org/shop/product/X, please place it in my basket, my username is "JohnDoe" and my password is "secretPassword".

Server

Okay, I've added 1 of http://example.org/shop/product/X into your basket, you can review your basket at http://example.org/shop/users/johndoe/basket

Client

I'd like to buy 1 of http://example.org/shop/product/Y as well, please place one in my basket, my username is "JohnDoe" and my password is "secretPassword".

Server

Okay, I've added 1 of http://example.org/shop/product/Y into your basket as well, you can still review your basket at http://example.org/shop/users/johndoe/basket

Client

Actually I don't want http://example.org/shop/product/X after all, please remove it from my cart, my username is "JohnDoe" and my password is "secretPassword".

Server

Okay, I've removed http://example.org/shop/product/X from your basket, you can review your updated basket at http://example.org/shop/users/johndoe/basket

Client

Okay I'm done, ring 'em up, my username is "JohnDoe" and my password is "secretPassword".

Server

Should I charge that to your expense account?

The thing to notice about this conversation is that it is stateless, every action from the client is independent of any other. This means that at any time, the user can run off and do something else, come back a few days later and carry on. It also means they could get some other service to add things to their shopping basket easily.

Riferimenti

Vivere senza sessioni

    
risposta data 18.08.2018 - 16:28
fonte

Leggi altre domande sui tag