¿Qué debería devolver una API de descanso para una guía vacía?

Un guid «vacío» sigue siendo un guid válido , así que analizarlo no debería requerir ninguna lógica adicional.

La pregunta es ¿por qué lo está usando? Me parece un error asignar un significado especial a un guid en particular, lo que lo convierte en un método mágico número.

Es un poco como decir que devolveré un int id, pero si es negativo, entonces es un código de error. ¡No lo hagas!

.. La razón es que en cada llamada a su función, el usuario tendrá que recordar comprobar si hay un valor de retorno negativo. Si se olvidan, ocurre un desastre.

De manera similar, si asigna a guid.empty un significado especial, todos los que llaman a su API deben escribir un cheque especial después de cada llamada.

It » Es mejor devolver un valor nulo (si corresponde) o lanzar una excepción (mediante un código de error HTTP, asumiendo un servicio REST).

Comentarios

• porque un día tendrá un código de advertencia, o un error 504.2 y no podrá comprimirlo en un número entero negativo, o una identificación negativa y todo el sistema se derrumbará
• es un poco lateral problema realmente. guid.empty (como cualquier otro guid específico) nunca se generará
• OP didn ‘ t asignó un significado especial a 00..00, el equipo de .Net lo hizo. La pregunta es si permitir o no que esta abstracción se filtre.
• @RubberDuck: el UUID nulo es en realidad parte del RFC que describe el UUID, por lo que la abstracción tiene ya » filtrado «. ref tools.ietf.org/html/rfc4122#section-4.1.7
• Bueno, @Newtopian, si ‘ es parte del RFC, entonces me parece completamente aceptable devolverlo en una respuesta API. Si el ‘ s idioma / biblioteca del cliente no ‘ t define una constante para él, ‘ es lo suficientemente simple como para crear uno y manejarlo apropiadamente.

Soy un desarrollador de iOS y No tengo idea de por qué su chico cree que necesita crear «un método de análisis». UUID(uuidString: valueFromServer) es todo lo que necesita hacer. Puede crear su UUID mágico simplemente:

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

Luego, puede comparar cualquier GUID con este GUID mágico.

Dicho esto, para todos los valores que provienen del servidor, el desarrollador de frontend debe primero verifique si el valor está allí, luego verifique si está bien formado (del tipo correcto). Si está devolviendo un valor mágico, entonces él debe también verificar si el el valor escrito correctamente es mágico. Al incluir el valor mágico, lo estás obligando a realizar una verificación adicional de if.

Como desarrollador de frontend, tengo que preguntar: ¿Por qué me estás obligando a aumentar la complejidad de mi aplicación?

Si puede argumentar que la interfaz debe tratar un GUID faltante de manera diferente que el GUID mágico, entonces tiene un argumento para devolverlo. De lo contrario, está agregando una complejidad innecesaria a la aplicación de interfaz.

(Adición en respuesta al comentario de @RubberDuck.)

Aquí está la cosa. El estándar JSON tiene una forma de tratar los valores nulos y el estándar GUID tiene una forma diferente de tratar los valores nulos. Dado que está enviando un GUID a través de JSON , esta última es la preocupación general (debido a que el GUID está envuelto en JSON), es el estándar que debe cumplir. Porque incluso si decide enviar un GUID nulo enviando un GUID lleno de ceros, el frontend todavía tiene que verificar el JSON nulo.

No fuerce a la interfaz para tratar con dos conceptos diferentes de nulo.

Comentarios

• Porque ‘ s parte del RFC? tools.ietf.org/html/rfc4122#section-4.1.7
• Oh, el placer de la complejidad accidental. Tengo que hacer que mi aplicación sea más compleja porque un comité de RFC tomó una decisión que no tiene sentido en mi sistema.
• No, usted hace que su aplicación sea más compleja, así que que su sistema se vuelve más flexible al aceptar un estándar bien definido. Además, si sus bibliotecas no ‘ t admiten el estándar de forma nativa, usted se queja y les pide que lo arreglen antes.
• O cambia el estándar porque ‘ es tonto. Los valores mágicos son los peores. Lo que sigue, un RFC que dice que un valor int de 0 es en realidad NULL ?

Haz lo que quieras (en lo que respecta a MacOS e iOS).

El desarrollo de iOS o MacOS r escribirá un método de análisis que verifica si sus datos JSON contienen una cadena y la convertirá en un objeto GUID o de alguna manera indicará una falla. Si envía un JSON nulo para indicar un guid no existente, también comprobarán si los datos JSON contienen un valor NSNull (). Eso es asumiendo que el desarrollador no es totalmente incompetente. Además, según su preferencia, utilizarán GUID opcionales y comprobarán si hay cero, o GUID no opcionales y tendrán una propiedad que verifica si un GUID es todo ceros. Eso es totalmente independiente de lo que haces.

En serio, puedes hacer lo que quieras (solo mantén la coherencia). Cualquier desarrollador que no sea totalmente incompetente estará bien. «Crear un método de análisis» es algo que se hace muy fácilmente. Como la mayoría de los desarrolladores de iOS, esto ni siquiera vale la pena discutirlo. Documente lo que está enviando. Crearé un método de análisis más rápido de lo que tomaría nuestra discusión.

Comentarios

• Sí, estoy de acuerdo contigo, controlo lo que se debe hacer, y lo haré. Y sé que el desarrollador de iOS preparará un analizador en un santiamén. ¿Pero es esta la respuesta correcta? Esperaba una respuesta más sólida … pero tal vez haya ´ t uno. Yo ´ dejaré que esto se macere por un rato y luego te daré la respuesta, nada mejor aparece.

Dado que en .NET Guid es un tipo de valor, no se le puede asignar el valor nulo.

Si necesitamos almacenar nulos en tipos de valor la solución normal es usar Nullable o como abreviatura usar la sintaxis? como en Guid? int? long? etc.

Esto también funcionará con serializadores estándar, por lo que el valor faltará o tendrá el literal valor nulo.

Comentarios

• Esben, esta respuesta no aborda OP ‘ s pregunta. Por favor, échale un vistazo más de cerca antes de responder.