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.
Cheers Jo On Sat, Nov 19, 2016 at 12:42 PM, Bhathiya Jayasekara <[email protected]> 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- > 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 <%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 > [email protected] > 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>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
