Cosa dovrebbe restituire unapi rest per un guid vuoto?

Un guid “vuoto” è ancora un guid valido , quindi analizzarlo non dovrebbe richiedere alcuna logica aggiuntiva.

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

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

..Il motivo è che in ogni chiamata alla tua funzione, lutente dovrà ricordarsi di controllare un valore di ritorno negativo. Se dimenticano, si verifica un disastro.

Allo stesso modo, se assegni a guid.empty un significato speciale, tutti coloro che chiamano la tua API devono scrivere un controllo speciale dopo ogni chiamata.

It ” È meglio restituire null (se appropriato) o lanciare uneccezione (tramite un codice di errore HTTP, assumendo un servizio REST).

Commenti

• perché un giorno avrai un codice di avviso, o un errore 504.2 e non sarai in grado di comprimerlo in un numero intero negativo o un id negativo e lintero sistema verrà sgretolato
• è un po un lato il problema realmente. guid.empty (come qualsiasi altro guid specifico) non verrà mai generato
• OP didn ‘ t assegnato alcun significato speciale a 00..00, il team .Net lha fatto. La domanda è se lasciare o meno trapelare questa astrazione.
• @RubberDuck: lUUID nullo fa effettivamente parte dellRFC che descrive lUUID, quindi lastrazione ha già ” trapelato “. ref tools.ietf.org/html/rfc4122#section-4.1.7
• Bene @Newtopian se ‘ fa parte della RFC, trovo completamente accettabile restituirlo in una risposta API. Se il client ‘ s lingua / libreria non ‘ definisce una costante per esso, ‘ è abbastanza semplice da crearne uno e gestirlo in modo appropriato.

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 magico GUID.

Detto questo, per tutti i valori che provengono dal server, lo sviluppatore del frontend deve prima controlla per vedere se il valore è lì, poi controlla per vedere se è ben formato (del tipo giusto). Se stai restituendo un valore magico, allora deve anche controllare se il il valore digitato correttamente è magico. Includendo il valore magico, lo costringi a fare un ulteriore controllo if.

In qualità di sviluppatore frontend, devo chiedere: per quale motivo mi costringi ad aumentare la complessità della mia app?

Se puoi sostenere che il frontend dovrebbe trattare un GUID mancante in modo diverso dal GUID magico, allora hai un argomento per restituirlo. Altrimenti stai aggiungendo una complessità non necessaria allapp di frontend.

(aggiunta in risposta al commento di @RubberDuck.)

Ecco il punto. Lo standard JSON ha un modo di trattare i valori nulli e lo standard GUID ha un modo diverso di trattare i valori nulli. Poiché stai inviando un GUID tramite JSON , questultimo è il problema generale (perché il GUID è racchiuso in JSON), è lo standard a cui dovresti conformarti .. Perché anche se decidi di inviare un GUID nullo inviando effettivamente un GUID pieno di zeri, il frontend ancora deve controllare il JSON nullo.

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

Commenti

• Perché ‘ fa parte della RFC? tools.ietf.org/html/rfc4122#section-4.1.7
• Oh, il piacere della complessità accidentale. Devo rendere la mia app più complessa perché un comitato RFC ha fatto una scelta che non ha senso nel mio sistema.
• No, rendi la tua app più complessa, quindi che il tuo sistema diventa più flessibile accettando uno standard ben definito. Inoltre, se le tue librerie non ‘ supportano nativamente lo standard, sollevi una puzza e chiedi loro di aggiustarlo a monte.
• Oppure ottieni la modifica dello standard perché ‘ è stupido. I valori magici sono i peggiori. Successivamente, una RFC che dice un valore int di 0 è in realtà NULL ?

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

Lo sviluppo iOS o MacOS r scriverà un metodo di analisi che controlla se i tuoi dati JSON contengono una stringa e la trasformano in un oggetto GUID o in qualche modo indicano un errore. Se invii un null JSON per indicare un guid non esistente, verificheranno anche se i dati JSON contengono un valore NSNull (). Questo presuppone che lo sviluppatore non sia totalmente incompetente. Inoltre, a seconda delle preferenze, utilizzeranno GUID facoltativi e verificheranno la presenza di GUID nulli o non facoltativi e avranno una proprietà che verifica se un GUID è tutto zero. Questo è totalmente indipendente da quello che fai.

Quindi seriamente, puoi fare quello che ti piace (mantienilo coerente). Qualsiasi sviluppatore non del tutto incompetente andrà benissimo. “Creare un metodo di analisi” è qualcosa che viene fatto molto facilmente. Come per lo più sviluppatore iOS, questo non vale nemmeno la pena di discuterlo. Documenta ciò che stai inviando. Creerò un metodo di analisi più velocemente di quanto richiederebbe la nostra discussione.

Commenti

• Sì, sono daccordo con te, controllo cosa dovrebbe essere fatto, e lo farò. E so che lo sviluppatore iOS creerà un parser in un batter docchio. Ma è questa la risposta giusta? Speravo in una risposta più concreta .. ma forse cè ´ t uno. ´ lascerò che questo marini per un po e poi ti darò la risposta niente di meglio.

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

Se è necessario memorizzare valori nulli nei tipi di valore la soluzione normale è usare Nullable o come abbreviazione usare la? sintassi come in Guid? int? long? ecc.

Funzionerà anche con serializzatori standard quindi il valore mancherà o avrà il valore letterale valore nullo.

Commenti

• Esben, questa risposta non riguarda lOP ‘ s domanda. Si prega di esaminarlo più a fondo prima di rispondere.