Hi Lahiru, One of the reasons to expose UUIDs instead of auto increment IDs in REST resources is that if we expose auto increment ID, we unwillingly expose certain internal information like how many resources we have in our system and the pattern how we store these resources. That information can be used as vulnerabilities for security attacks. Due to the same reason, it's kind of a standard to use UUIDs instead of auto increment IDs in REST world. You can find some detailed explanations about that on the web[1][2].
[1] http://stackoverflow.com/questions/12378220/api-design-and-security-why-hide-internal-ids [2] http://blogs.perl.org/users/ovid/2014/11/stop-putting-auto-increment-ids-in-urls.html Thanks, Bhathiya On Sat, Nov 19, 2016 at 12:12 PM, Lahiru Cooray <[email protected]> wrote: > Hi Uvindra, > The reason you mentioned is: > "Having a UUID for this purpose means that end users cannot guess the > possible unique identity of other entities, which is possible if we exposed > an integer based identifier." > > What is the purpose of having a non guessable Id here? Anywhere the user > who has permissions to invoke api's can get the uuid list or simply can > view in the Store/Publisher UI. If there are any more implementation > constraints (eg: user should be able to delete api's only in his tenant > domain, etc) should be handle internally. > > What I'm trying to highlight is, we should only move to a hybrid approach > only if there's a valid use case. Else it's less complex if we can move > only with the auto increment Id. > > [Solution we discuss here can also be reused in AppM c5 upgrade] > > > > On Fri, Nov 18, 2016 at 11:27 PM, Uvindra Dias Jayasinha <[email protected] > > wrote: > >> We expose the unique UUID of a given artifact to the end user via REST >> APIs. You can see how this is used in the REST API docs[1]. We cant use the >> auto increment ID for this purpose for the reasons I mentioned earlier. >> >> [1] https://docs.wso2.com/display/AM200/apidocs/publisher/index.html >> >> On 18 November 2016 at 22:48, Lahiru Cooray <[email protected]> wrote: >> >>> Hi, >>> >>> I was under the impression that the UUID was used as a result of having >>> registry and UUID was used to map the registry resource. Pls correct me if >>> I'm wrong. >>> >>> When the registry is no longer present, I don't see a real use case of >>> going for a hybrid approach. Either we could use UUID as a PK or an auto >>> increment ID. >>> >>> In this case +1 for an auto increment ID as the PK. >>> Reasons: easy to debug manually/ easy to sort by id/ save space >>> >>> On Fri, Nov 18, 2016 at 9:34 PM, Uvindra Dias Jayasinha < >>> [email protected]> wrote: >>> >>>> We already have a UUID column for few tables such as AM_API and >>>> AM_APPLICATION which is used to uniquely identify a record. The reason why >>>> we have a UUID column is because it is the unique identifier that we expose >>>> to the end user. Having a UUID for this purpose means that end users cannot >>>> guess the possible unique identity of other entities, which is possible if >>>> we exposed an integer based identifier. >>>> >>>> However at table level we were still maintaining an auto incrementing >>>> primary key. So the UUID was used externally but the integer key was used >>>> privately to maintain foreign key relationships within the schema. >>>> >>>> We first thought it might be a good idea to dispense of the auto >>>> incrementing primary key and use the UUID as the primary key itself since >>>> it seemed like we had two columns that served somewhat duplicate purposes. >>>> But I have been doing some research regarding this and have found that the >>>> industry is divided a bit regarding this point. >>>> >>>> These links advocate UUIDs as primary keys >>>> https://blog.codinghorror.com/primary-keys-ids-versus-guids/ >>>> https://www.clever-cloud.com/blog/engineering/2015/05/20/why >>>> -auto-increment-is-a-terrible-idea/ >>>> >>>> These links recommend auto incrementing integers as primary keys >>>> http://stackoverflow.com/questions/404040/how-do-you-like-yo >>>> ur-primary-keys/404057#404057 >>>> http://stackoverflow.com/questions/829284/guid-vs-int-identity >>>> >>>> We can still continue with our hybrid approach of having both an auto >>>> incriminating integer as primary key and using the UUID for external >>>> interactions, whihc seems to be also used by some to get the best of both >>>> worlds. >>>> >>>> >>>> So how should we proceed? >>>> >>>> -- >>>> Regards, >>>> Uvindra >>>> >>>> Mobile: 777733962 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Lahiru Cooray* >>> Software Engineer >>> WSO2, Inc.;http://wso2.com/ >>> lean.enterprise.middleware >>> >>> Mobile: +94 715 654154 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Lahiru Cooray* > Software Engineer > WSO2, Inc.;http://wso2.com/ > lean.enterprise.middleware > > Mobile: +94 715 654154 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Bhathiya Jayasekara* *Senior Software Engineer,* *WSO2 inc., http://wso2.com <http://wso2.com>* *Phone: +94715478185* *LinkedIn: http://www.linkedin.com/in/bhathiyaj <http://www.linkedin.com/in/bhathiyaj>* *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* *Blog: http://movingaheadblog.blogspot.com <http://movingaheadblog.blogspot.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
