Perché è prassi comune codificare i cursori di impaginazione oi valori id come stringa?

Question

Ad esempio l'API di Facebook Graph: perché i numeri codificati di base64 sono after e before?

{ 
    "data": [ 
    ... Endpoint data is here 
    ], 
    "paging": { 
    "cursors": { 
     "after": "MTAxNTExOTQ1MjAwNzI5NDE=", 
     "before": "NDMyNzQyODI3OTQw" 
    }, 
    "previous": "https://graph.facebook.com/me/albums?limit=25&before=NDMyNzQyODI3OTQw" 
    "next": "https://graph.facebook.com/me/albums?limit=25&after=MTAxNTExOTQ1MjAwNzI5NDE=" 
    } 
} 

Quali vantaggi potrebbe forse portare a differenza di solo numeri normali?

Come mostra il registro pitone, i benefici non possono essere la rappresentazione più breve dei dati o dei dati contenenti caratteri non sicuri:

>>> base64.b64decode("MTAxNTExOTQ1MjAwNzI5NDE=") 
'10151194520072941' 
>>> len('10151194520072941') 
17 
>>> len("MTAxNTExOTQ1MjAwNzI5NDE=") 
24 

Answer 1

Maggior numero possibile in JavaScript è 9007199254740992 in base alle domanda posta nel StackOverflow What is JavaScript's highest integer value that a Number can go to without losing precision?

Se si confrontano questi valori

9007199254740992 // the JS maximum 
10151194520072941 // the Base64 encoded number 

Se certamente si presenta come Facebook è internamente - per motivi che non conosciamo - la memorizzazione valori troppo grandi per la precisione del numero di JavaScript da gestire.

Quindi, a me sembra che non avessero altra possibilità che gestire numeri come stringhe.

Ovviamente potevano usare solo "10151194520072941" come numero in formato stringa, ma alcuni programmatori potrebbero confondere questo come un numero. Anche se questo accade raramente, probabilmente pensavano che Base64 codificando il numero evitasse il problema di qualcuno che convertisse la stringa in numero intero.

Inoltre, poiché questa è funzione API pubblica, non viene utilizzata dai propri ingegneri, quindi il rischio è ancora più elevato, perché le persone che utilizzano l'API provengono da diversi contesti educativi. Potrebbero utilizzare accidentalmente ad esempio parseInt o simili al numero risultante in richieste di assistenza clienti non necessarie.

MODIFICA: L'utilizzo di numeri molto grandi potrebbe anche servire a un altro scopo: rilevare l'abuso intenzionale dell'API.Se usassero per esempio valori UUID casuali o valori numerici consecutivi, qualsiasi valore close-by potrebbe essere potenzialmente legale. Se si tratta di un UUID, devono prima fare la richiesta per vedere se si tratta di una voce legale. Avendo una grande base di numeri potrebbe essere che solo ogni 1000 è legale o seguono qualche altra regola matematica che può essere rilevata da un singolo server, senza richieste ad altri server, smistando i client che stanno costruendo intenzionalmente richieste con valori illegali diventa molto più efficace e forse può essere filtrato prima che raggiungano i database.

Answer 2

Se vuoi dire con base 10 (decimale) quando dici pianura numeri, quindi i vantaggi sono che la base 64 è più compatta, utilizzando meno cifre (un numero 10 base 10 cifre (es. 1.000.000.000) può essere espresso in sole 5 cifre nella base 64 (es. F9eEA)), così come (come dici tu) nascondendo i dettagli di implementazione.

Se si intende utilizzare i dati binari non elaborati quando si esprimono numeri semplici, la base 64 utilizza caratteri che sono quasi sempre sicuri da trasmettere su Internet, in URL, ecc. Senza che alcuni caratteri vengano interpretati come caratteri di controllo (che è un rischio durante la trasmissione dei dati binari non elaborati). vedi this other question per ulteriori informazioni.

In entrambi i casi, l'utilizzo di base64 presenta alcuni vantaggi.

EDIT:

Capisco quello che vuoi dire, i vantaggi elencati in precedenza non si applicano in questo caso. Facebook probabilmente ha usato base64 per coerenza con le altre funzioni API, oltre a nascondere i dettagli di implementazione. Potrebbe anche essere vantaggioso se lo modificassero in futuro per consentire altri caratteri, oltre a tollerare potenziali richieste malformate (supponendo che l'errore sia avvenuto prima della conversione di base64).