Hi Bathiya/Jo, Thanks for the valuable information. +1 for UUID as the PK
On Sat, Nov 19, 2016 at 3:41 PM, Joseph Fonseka <jos...@wso2.com> wrote: > > > On Sat, Nov 19, 2016 at 3:38 PM, Joseph Fonseka <jos...@wso2.com> wrote: > >> Hi All >> >> Another most obvious advantage of using UUIDs would that it will simplify >> import/export of APIs. I am +1 for using UUIDs as primary keys. >> > > In a more correct term UUIDs will simplify managing APIs cross > environments. > > >> >> Cheers >> Jo >> >> On Sat, Nov 19, 2016 at 12:42 PM, Bhathiya Jayasekara <bhath...@wso2.com> >> wrote: >> >>> 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-a >>> nd-security-why-hide-internal-ids >>> [2] http://blogs.perl.org/users/ovid/2014/11/stop-putting-auto-i >>> ncrement-ids-in-urls.html >>> >>> Thanks, >>> Bhathiya >>> >>> On Sat, Nov 19, 2016 at 12:12 PM, Lahiru Cooray <lahi...@wso2.com> >>> 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 < >>>> uvin...@wso2.com> 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 <lahi...@wso2.com> 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 < >>>>>> uvin...@wso2.com> 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 >>>>>>> Architecture@wso2.org >>>>>>> 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 >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Uvindra >>>>> >>>>> Mobile: 777733962 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> 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 >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Bhathiya Jayasekara* >>> *Senior Software Engineer,* >>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>> >>> *Phone: +94715478185 <%2B94715478185>* >>> *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 >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> -- >> *Joseph Fonseka* >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 772 512 430 >> skype: jpfonseka >> >> * <http://lk.linkedin.com/in/rumeshbandara>* >> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
