3

I have a .net api backend for mobile apps and the question came up (in conversation with the iOS develper) if a JSON response for an empty GUID should return:

  • 00000000-0000-0000-0000-000000000000
  • or null (by having the return type nullable Guid type (Guid?)

If the first one, the mobile developer needs to create a parse method for that and not use his regular generic null check function.

In C# you would just do

if (guid == Guid.Empty)

But the iOS developer talks about creating a parsing method (so not build in I guess).

But I can´t find any discussion on what is considered "best practice" or even how native apps are dealing with empty/null Guid's.

I know what I like to do but what do you think I should do?

Improve this question
13
  • Firstly, what's he do if it's not an empty GUID? Also, why does he need a parse method for empty but not a non-empty GUID? Can't he just do an equality check against the string "00000000-0000-0000-0000-000000000000"?
    – Kevin Fee
    Jun 22, 2017 at 17:20
  • 4
    Empty Guid is different than non-existing Guid. By all means the convention of empty on .Net is 00....00, but you may not want to leak this convention to a public API that's used by other platforms. Instead of trying to define what's empty and what's not, you have to define the meaning of having and not having a Guid, use a convention that would be easy for all platforms (web, IOS, Android, etc...) and keep it as the protocol.
    – Machado
    Jun 22, 2017 at 17:21
  • 2
    @Machado well is it a .net convention? "The "nil" UUID, a special case, is the UUID" en.wikipedia.org/wiki/Universally_unique_identifier#Standards
    – Sturla
    Jun 23, 2017 at 10:29
  • 2
    I suspect .Net only has Guid.Empty because in the 1.0 release there were no generics and no Nullable<T>, so Empty became a stand in to mean null, since Guid is a value type, but its not actually a valid guid value. In the code base I work in today, for some reason there are Guid?s everywhere, and both Empty and null semantically mean the same thing. Its pretty annoying, and I've been making the Guid's non-nullable so I don't have to keep checking both cases, but that's only because there's now way to get rid of Guid.Empty.
    – Andy
    Jun 24, 2017 at 12:46
  • 1
    There's an important difference between an "empty" constant and null: one will cause NREs and the other won't. Both need to be checked and handled, so pick your poison. Want to fail fast, or fail silently?
    – RubberDuck
    Jun 24, 2017 at 13:11

4 Answers 4

Reset to default
5

An 'empty' guid is still a valid guid, so parsing it shouldn't require any extra logic.

The question is why are you using it at all? It seems like a mistake to me to assign special meaning to a particular guid, making it a magic number.

It's a bit like saying I'll return an int id, but if it's negative then it's an error code. Don't do it!

..The reason being that in every call to your function, the user will have to remember to check for a negative return value. If they forget, disaster occurs.

Similarly, if you assign guid.empty a special meaning, everyone who calls your API has to write a special check after every call.

It's better to return null (if appropriate) or throw an exception (via an HTTP error code, assuming a REST service).

Improve this answer
7
  • because one day you will have a warning code, or an error 504.2 and not be able to squeeze it into a negative integer, or a negative id and the whole system will come crumbling down
    – Ewan
    Jun 23, 2017 at 8:25
  • its a bit of a side issue really. guid.empty (like any other specific guid) will never be generated
    – Ewan
    Jun 23, 2017 at 8:28
  • 1
    OP didn't assign any special meaning to 00..00, the .Net team did. The question is whether or not to let this abstraction leak.
    – RubberDuck
    Jun 24, 2017 at 12:59
  • 2
    @RubberDuck: the nil UUID is actually part of the RFC that describes UUID so the abstraction has already "leaked". ref tools.ietf.org/html/rfc4122#section-4.1.7
    – Newtopian
    Jul 4, 2017 at 14:27
  • 2
    Well @Newtopian if it's part of the RFC, then I find it completely acceptable to return it in an API response. If the client's language/library doesn't define a constant for it, it's simple enough to create one and handle appropriately.
    – RubberDuck
    Jul 4, 2017 at 14:29
1

I'm an iOS developer and I have no idea why your guy thinks he needs to create "a parsing method." UUID(uuidString: valueFromServer) is all he needs to do. He can create your magic UUID by simply:

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

Then he can compare any GUID to this magic GUID.

That said, for all values that come from the server, the frontend developer must first check to see if the value is there, then check to see if it's well formed (of the right type.) If you are returning a magic value, then he must also check to see if the correctly typed value is magic. By including the magic value, you are forcing him to make an additional if check.

As a frontend developer, I have to ask: For what reason are you forcing me to increase the complexity of my app?

If you can make an argument that the frontend should treat a missing GUID differently than the magic GUID, then you have an argument for returning it. Otherwise you are adding unnecessary complexity to the frontend app.

(Addition in response to @RubberDuck's comment.)

Here's the thing. The JSON standard has one way of dealing with null values and the GUID standard has a different way of dealing with null values. Since you are sending a GUID through JSON, the latter is the overarching concern (because the GUID is being wrapped in JSON,) it is the standard you should conform to... Because even if you decide to send a null GUID by actually sending a GUID full of zeros, the frontend still has to check for the JSON null.

Don't force the front end to deal with two different concepts of null.

Improve this answer
4
  • Because it's part of the RFC? tools.ietf.org/html/rfc4122#section-4.1.7
    – RubberDuck
    Jul 4, 2017 at 14:31
  • Oh the joys of accidental complexity. I have to make my app more complex because some RFC committee made some choice that makes no sense in my system.
    – Daniel T.
    Jul 4, 2017 at 14:35
  • No, you make your app more complex so that your system becomes more flexible by accepting a well defined standard. Also, if your libs don't natively support the standard, you raise a stink and ask them to fix it upstream.
    – RubberDuck
    Jul 4, 2017 at 14:38
  • Or you get the standard changed because it's dumb. Magic values are the worst. What next, an RFC that says an int value of 0 is actually NULL?
    – jam40jeff
    Oct 29, 2019 at 12:43
0

Do what you like (as far as MacOS and iOS are concerned).

The iOS or MacOS developer will write a parsing method that checks if your JSON data contains a string and turn it into a GUID object or somehow indicate failure. If you send a JSON null to indicate a non-existing guid they will also check whether the JSON data contains an NSNull() value. That's assuming the developer isn't totally incompetent. In addition, depending on their preference they will either use optional GUIDs and check for nil, or non-optional GUIDs and have a property that checks if a GUID is all zeroes. That's totally independent of what you do.

So seriously, you can do what you like (just keep it consistent). Any not totally incompetent developer will be just fine. "Creating a parsing method" is something that is done very easily. As mostly iOS developer, this isn't even worth discussing. Document what you are sending. I'll create a parsing method quicker than our discussion would take.

Improve this answer
1
  • Yes I agree with you, I control what should be done, and I will. And I know the iOS developer will whip up a parser in a jiffy. But is this the right answer? I was hoping for a more solid answer.. but maybe there is´t one. I´ll let this marinate for little while and then give you the answer nothing better comes along.
    – Sturla
    Jun 26, 2017 at 23:12
-2

Since in .NET Guid is a value type it cannot be assigned the value null.

If we need to store nulls in value types the normal solution is to use Nullable or as a shorthand use the ? syntax like in Guid? int? long? etc.

This will also work with standard serializers so the value will be either missing or have the literal null value.

Improve this answer
1
  • 3
    Esben, this answer does not address OP's question. Please take a deeper look into it before answering.
    – Machado
    Jun 22, 2017 at 18:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.