Hi Saptarshi, Sorry, and of course, I meant..
*I do not really see a need for searching by internal ID.* Was a bit confused by some of the mails higher up in this thread. Regards, Jason On Tue, Nov 5, 2013 at 6:47 AM, Jason Pickering <jason.p.picker...@gmail.com > wrote: > Hi Saptarshi, > I do not really see a need for searching by UID. As Lars and other devs > have made clear, there is only one ID, and that is the UID. I do find it a > bit confusing, as we have historically referred to the ID as the internal > ID, but that was before the WebAPI. I have in the past really wanted a way > to do this as well for various reasons, namely for direct injection of data > into the database with SQL. But with the API now quite robust, I have been > moving more and more away from that. With that in mind, I am not sure you > ever really need the internal ID. > > I am not opposed to it really and think it would be a nice to have (just > as it would to be able to search on any property of an object), but what is > the real use case here? > > Regards, > Jason > > PS. +1 for Bob's suggestion of having an explicit endpoint. > > > On Tue, Nov 5, 2013 at 4:38 AM, Bob Jolliffe <bobjolli...@gmail.com>wrote: > >> Hi Saptarshi >> >> I don't think the intent was to ever expose the internal id at all so >> maybe the docs are a bit misleading. I'd suggest changing id to uid in the >> docs. >> >> Whether it makes sense to search by uid or not is another matter. There >> might be some fringe cases, but on the whole I would agree there is already >> a url which will get a resource based on its uid so I struggle to see what >> searching adds. Though it doesn't do much harm, particularly if we change >> the docs. What it can be much more important is to get hold of a resource >> by its unique code. Thats where this search functionality worries me a >> little. >> >> If I search for a dataelement with code of 'DE_34' I'd rather be able to >> explicitly do that rather than potentially also getting matching names. So >> urls like "/api/dataElements/search&code=DE_34" work better for me than >> "/api/dataElements/search/DE_34" >> >> Bob >> >> >> >> >> On 4 November 2013 22:10, Saptarshi Purkayastha <sun...@gmail.com> wrote: >> >>> Brajesh, >>> There are too many people on this mailing list and I think its >>> inappropriate to spam everyone with out-of-topic and in my opinion >>> nonsensical sentences. >>> I consider this trolling and I request you not to send such emails. >>> >>> Core team, >>> 1. Do you agree this is a valid requirement? or will this never be >>> implemented? >>> 2. Should we just remove search by uid? >>> >>> --- >>> Regards, >>> Saptarshi PURKAYASTHA >>> >>> ------------------------------ >>> Date: Tue, 5 Nov 2013 03:54:04 +0800 >>> From: brajesh.mur...@yahoo.com >>> To: mlati...@gmail.com; l...@roland.bz >>> CC: dhis2-devs@lists.launchpad.net >>> >>> Subject: Re: [Dhis2-devs] Web API - Search by id >>> >>> >>> Hello Mobilars and Saptarshi, >>> >>> Agreed with SOAP is now old fashioned, but we should remember one thing >>> that DHIS2 development programme and its deployment is primarily focused on >>> developing and under developed country to improve their Health, Nutrition >>> and Population Sector Program and its primary diameter of development(but >>> not radious of development) should be focused on Mother and Child Health >>> (MCH) as well as Rehabilitation and Child Health (RCH) Programme only. I am >>> sure in most of the developing and under developed countries from kids to >>> their parents even house surgeon and clinical doctors still they are using >>> every day SOAP products to make their hands clean and jerms protected. >>> >>> But i am little bit surprised suspicious with Mobilars and Saptarshi, >>> whether you both are using it or not in your day to day life, perhaps quite >>> sure 100 % that Weivao and Alex both have started using it every day to >>> make their hands clean and jirms protected. >>> >>> Agreed with Mobilars that SOAP is old fashioned now a days and there are >>> so much new developments has been happened in this area, but still these >>> days there are so many old fashioned concepts are being used in developing >>> and under developed countries like long back Fat Man (FM) doped in Nagasaki >>> detonation causes nuclear explosion and destroying so many lives, but now a >>> days in so many metropolitan cities this FM concept are being used as >>> doping melodious musics, news, game commentary various live saving >>> advertisements and so many audio programmes to make ppl feel good and enjoy >>> their every day life. >>> >>> So in short, i can say, adhering to the old fashioned ideas like >>> SOAP/Knut and HTTP/Bob interfaces are not as bad as just quickly sticking >>> with alpha release of REST type of several applied science products and >>> api's like examination controllers which are not even properly tested and >>> pass user acceptance test for expected requirements. For mapping and >>> searching single resource, i think no need to use url as co-ordinate >>> geomatory type of concept with multiple url for finding and searching one >>> resource kept in DHIS 2 deployed application, rather it should be more >>> clear in requirement analysis that target object or resource is static, not >>> moving projectile. I think in DHIS 2 application development program, >>> resources are in web-apps deployed on web server and its more likely static >>> some where at a particular instance of time frame not inside flying >>> machine. >>> >>> Agreed with Saptarshi, requirement is little tough to use SOAP in DHIS 2 >>> development programe, perhaps I think more qualified ppls thinks simple >>> problems in more complex ways, because they put so many bundles of unwanted >>> ideas in their head and that comes and reflect in their new development >>> programme areas leads and produce new development products and approach of >>> simple thing in more complex paralytic ways. And Saptarshi, you can't >>> be-leave, i know some of the Phd aspirants rangers engaged in DHIS 2 >>> development programme, they even don't take proper shower every day not >>> because they are not aware about its use and implications but rather >>> because their head are full with other process and they don't have that >>> much of time to go for shower, pardon but their uid's are quite >>> confidential in India. Therefor I am expecting SOAP web api module >>> development programme should have ppl who are only bachelors and enrolled >>> in DHIS 2 development programme and should be engaged in any family welfare >>> health programme. >>> If such team is available than its fine if not than it must be >>> introduced in DHIS 2 development programe so that they can think about the >>> prospective in more likely neutral way not likely ionized way. >>> >>> Regards, >>> Brajesh Murari >>> >>> >>> >>> On Monday, 4 November 2013 10:21 PM, Murod Latifov <mlati...@gmail.com> >>> wrote: >>> And of course if one does not belong to any of those >>> categories listed by Brajesh. >>> To me it looks like no one gets qualified for this job, inside and >>> outside DHIS2 team. Very tough requirements Brajesh. Agree with Mobilarsh >>> on open source concept though. >>> >>> Best of luck Brajesh! >>> >>> On Mon, Nov 4, 2013 at 9:35 PM, Lars Kristian Roland <l...@roland.bz>wrote: >>> >>> Not sure if this was ironic, but in case it wasn't: I respectfully >>> disagree. SOAP is old fashioned and should not be woken from the dead. >>> But it is open source software, so one may of course implement SOAP if >>> one feels this is better. >>> Best regards >>> Mobilars >>> 4. nov. 2013 17:28 skrev "Brajesh Murari" <brajesh.mur...@yahoo.com> >>> følgende: >>> >>> I think its time to introduce and develop new module which should be >>> based on Simple Object Architecture Protocol (SOAP), as from the trail mail >>> it shows REST APIs are not in a position to provide secure layers for >>> finding resources, in other words we can say REST APIs are one of the >>> biggest failure in DHIS2 application development. I would request to the >>> list and the DHIS2 global application development team to introduce some >>> developer to work and try to develop DHIS2 web api using SOAP but make sure >>> the team engaged in development of this new SOAP based api should not >>> contain any married developer nor they should be Post Graduate or Phd >>> holder at all in any deciplene nor they should be any consultant or >>> solution architect. This team should belong to simple developer with fresh >>> mind and make sure that team should not contain any developer who has all >>> ready celebrated their silver jubilee in application development. >>> >>> Regards, >>> Brajesh Murari >>> >>> >>> >>> On Monday, 4 November 2013 9:34 PM, Saptarshi Purkayastha < >>> sun...@gmail.com> wrote: >>> It is generally considered to be bad practice in the design of Web >>> API or REST APIs that two URLs point to the same resources. >>> Also I would think that people who want to juggle between existing web >>> functionality and Web API, would like to use internal IDs to get the UID >>> and then use the UID for web API calls. This makes it more flexible to use >>> and switch between the two IDs depending what functionality you want to >>> use, either from core web interface (uses IDs) or Web API (uses UIDs) >>> >>> --- >>> Regards, >>> Saptarshi PURKAYASTHA >>> ------------------------------ >>> From: janhenrik.overl...@gmail.com >>> Date: Mon, 4 Nov 2013 16:57:26 +0100 >>> Subject: Re: [Dhis2-devs] Web API - Search by id >>> To: sun...@gmail.com >>> CC: dhis2-devs@lists.launchpad.net >>> >>> It's just for convenience. If you make an app that looks up organisation >>> units by id, code or name you won't have to change the base url based on >>> the parameter. >>> >>> >>> On Mon, Nov 4, 2013 at 4:47 PM, Saptarshi Purkayastha >>> <sun...@gmail.com>wrote: >>> >>> Why would one use the search at all in this case of using the UID? >>> You can directly get the resource with the UID >>> http://apps.dhis2.org/demo/api/organisationUnits/ImspTQPwCqd gives >>> Sierra Leone >>> http://apps.dhis2.org/demo/api/organisationUnits/search/Sierra%20Leoneis >>> the search >>> >>> --- >>> Regards, >>> Saptarshi PURKAYASTHA >>> ------------------------------ >>> From: janhenrik.overl...@gmail.com >>> Date: Mon, 4 Nov 2013 16:36:25 +0100 >>> Subject: Re: [Dhis2-devs] Web API - Search by id >>> To: sun...@gmail.com >>> CC: dhis2-devs@lists.launchpad.net >>> >>> >>> Hi, try the uid. For a web API user there is only one id (which is the >>> uid). We don't want to confuse him by saying "uid" in the docs as it >>> implies that there is an "id" as well. >>> >>> >>> On Mon, Nov 4, 2013 at 4:11 PM, Saptarshi Purkayastha >>> <sun...@gmail.com>wrote: >>> >>> The Web API documentation here: >>> http://www.dhis2.org/doc/snapshot/en/user/html/ch25s04.html >>> suggests that you can search a resource by its id, code and name. >>> I tried the following: >>> http://apps.dhis2.org/demo/api/organisationUnits/search/559 >>> But it says >>> >>> Object not found for query: 559 >>> >>> So, does it only work for code and name and not for id? >>> >>> --- >>> Regards, >>> Saptarshi PURKAYASTHA >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dhis2-devs >>> Post to : dhis2-devs@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dhis2-devs >>> Post to : dhis2-devs@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dhis2-devs >>> Post to : dhis2-devs@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dhis2-devs >>> Post to : dhis2-devs@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> >>> >>> _______________________________________________ Mailing list: >>> https://launchpad.net/~dhis2-devs Post to : >>> dhis2-devs@lists.launchpad.net Unsubscribe : >>> https://launchpad.net/~dhis2-devs More help : >>> https://help.launchpad.net/ListHelp >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dhis2-devs >>> Post to : dhis2-devs@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dhis2-devs >> Post to : dhis2-devs@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
