Cosa dovrebbe restituire un api di riposo per un guid vuoto?

Un guid 'vuoto' è ancora un valido guid, quindi l'analisi non dovrebbe richiedere alcuna logica aggiuntiva.

La domanda è: perché la stai usando? Mi sembra un errore assegnare un significato speciale a un particolare guid, rendendolo un numero magico.

È un po 'come dire che restituirò un ID int, ma se è negativo, allora è un codice di errore. Non farlo!

.. Il motivo è che in ogni chiamata alla tua funzione, l'utente dovrà ricordare di verificare un valore di ritorno negativo. Se dimenticano, si verifica un disastro.

Allo stesso modo, se assegni a guid.empty un significato speciale, chiunque chiami la tua API deve scrivere un controllo speciale dopo ogni chiamata.

È meglio restituire null (se appropriato) o lanciare un'eccezione (tramite un codice di errore HTTP, ipotizzando un servizio REST).

Sono uno sviluppatore iOS e non ho idea del motivo per cui il tuo ragazzo pensa di aver bisogno di creare "un metodo di analisi". UUID(uuidString: valueFromServer) è tutto ciò che deve fare. Può creare il tuo UUID magico semplicemente:

extension UUID {
    static var zero: UUID { return UUID(uuidString: "00000000-0000-0000-0000-000000000000")! }
}

Quindi può confrontare qualsiasi GUID con questo GUID magico.

Detto questo, per tutti i valori che provengono dal server, lo sviluppatore frontend deve prima controllare se il valore è presente, quindi controllare se è ben formato (del tipo giusto). Se stai restituendo una magia valore, quindi deve anche controllare per vedere se il valore tipizzato correttamente è magico. Includendo il valore magico, lo stai costringendo a fare un ulteriore controllo.

Come sviluppatore di frontend, devo chiedere: per quale motivo mi stai costringendo ad aumentare la complessità della mia app?

Se puoi fare una discussione sul fatto che il frontend debba trattare un GUID mancante diverso rispetto al GUID magico, allora hai un argomento per restituirlo. Altrimenti si aggiunge complessità non necessaria all'app frontend.

(aggiunta in risposta al commento di @ RubberDuck.)

Ecco la cosa. Lo standard JSON ha un modo di trattare valori null e lo standard GUID ha un modo diverso di trattare valori nulli. Dato che stai inviando un GUID tramite JSON , quest'ultimo è il problema dominante (poiché il GUID è in fase di wrapping in JSON) è lo standard che dovresti conformare a .. Perché anche se si decide di inviare un GUID null inviando effettivamente un GUID pieno di zeri, il frontend ancora deve controllare il JSON null.

Non forzare il front end a gestire due concetti diversi di null.

Fai ciò che ti piace (per quanto riguarda MacOS e iOS).

Lo sviluppatore iOS o MacOS scriverà un metodo di analisi che controlla se i dati JSON contengono una stringa e la trasformano in un oggetto GUID o indicano in qualche modo un errore. Se si invia un nullo JSON per indicare un guid non esistente, si controllerà anche se i dati JSON contengano un valore NSNull (). Ciò presuppone che lo sviluppatore non sia totalmente incompetente. Inoltre, in base alle loro preferenze, utilizzeranno GUID facoltativi e verificheranno la presenza di GUID nul o non facoltativi e avranno una proprietà che controlla se un GUID è tutti zero. Questo è totalmente indipendente da ciò che fai.

Quindi seriamente, puoi fare ciò che vuoi (mantienilo coerente). Qualunque sviluppatore non totalmente incompetente andrà bene. "Creare un metodo di analisi" è qualcosa che viene fatto molto facilmente. Per lo più sviluppatore iOS, non vale nemmeno la pena di discuterne. Documenta ciò che stai inviando. Creerò un metodo di analisi più veloce di quanto la nostra discussione potrebbe prendere.

Poiché in .NET Guid è un tipo di valore non può essere assegnato il valore null.

Se abbiamo bisogno di memorizzare valori nulli in tipi di valore, la soluzione normale è usare Nullable o usare una scorciatoia? sintassi come in Guid? int? lungo? ecc.

Funzionerà anche con serializzatori standard, quindi il valore sarà mancante o avrà il valore nullo letterale.