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- >> increment-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
