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
