It depends.
Objects are Secret
If the data being uploaded with those GUID is considered secret, then you do not want users to share the same GUID. For that reason, you want to include another identifier in your primary key to make sure that each customer has its own set of GUIDs. In other words, as Conor mentioned in his comment, every user would be able to create an object with GUID 12345
and the customer has no clue that another customer also has a object with GUID 12345
.
You can easily do that by adding the customer identifier to the GUID to identify the object(s) on a per customer basis.
Note that in this case you would also include a way to identify the user since the data is secret. Either a long UUID like string that was given to the user when they logged in or directly the credentials of the user (that one only works if only the costumer's server access your server since such credentials.)
Objects are Public
When objects are anyway public, there is no real security issue. However, it puts a burden on the client which is to generate a new GUID when an upload fails because of a clash.
Now, a GUID should be unique so the possibility of a clash is minimal. It probably would happen because a hacker is trying to find objects which said hacker should not otherwise know exists.
Since the data is public, though, having a hacker find it is not big deal. It's available to them one way or another...
Identifier
The idea of an identifier that gets incremented has been used a lot and it is still being used a lot.
If the data the identifier references is public, then it is not important to have a number incremented one by one like this.
However, something that should remain somewhat secret should not use such numbers. This is because a hacker can easily check for all the objects by using a URL such as:
http://example.com/user/1
http://example.com/user/2
http://example.com/user/3
...
http://example.com/user/n
Now we can see that the hacker can find all the users. If the user's account is public, he can check their name, with that name, they can attempt a login with some random password. So you do have a vector of attack which is simplified.
Create vs Modify
Yes. This mechanism is used by many systems, especially in the NoSQL world. For example, Cassandra let you use INSERT
or UPDATE
to create and/or modify content.
Cassandra has one column which is called the PRIMARY KEY
(as in SQL, only it can not be more than one column). That PRIMARY KEY
is used to index the data. This is the same as your GUID only can be absolutely anything, including binary data.
12345
but some other customer already created a record with that GUID, what happens? Do I overwrite their record, or do we both just get a record with GUID12345
and have no way to tell that someone else is using the same? I'm guessing the former, in which case this is a bad idea, but I want to confirm before attempting an answer.