dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #25937
Re: Web API - Search by id
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 <sunbiz@xxxxxxxxx> 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.murari@xxxxxxxxx
> To: mlatifov@xxxxxxxxx; lars@xxxxxxxxx
> CC: dhis2-devs@xxxxxxxxxxxxxxxxxxx
>
> 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 <mlatifov@xxxxxxxxx>
> 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 <lars@xxxxxxxxx>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.murari@xxxxxxxxx>
> 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 <
> sunbiz@xxxxxxxxx> 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.overland@xxxxxxxxx
> Date: Mon, 4 Nov 2013 16:57:26 +0100
> Subject: Re: [Dhis2-devs] Web API - Search by id
> To: sunbiz@xxxxxxxxx
> CC: dhis2-devs@xxxxxxxxxxxxxxxxxxx
>
> 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 <sunbiz@xxxxxxxxx>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%20Leone is
> the search
>
> ---
> Regards,
> Saptarshi PURKAYASTHA
> ------------------------------
> From: janhenrik.overland@xxxxxxxxx
> Date: Mon, 4 Nov 2013 16:36:25 +0100
> Subject: Re: [Dhis2-devs] Web API - Search by id
> To: sunbiz@xxxxxxxxx
> CC: dhis2-devs@xxxxxxxxxxxxxxxxxxx
>
>
> 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 <sunbiz@xxxxxxxxx>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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> 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.netUnsubscribe :
> https://launchpad.net/~dhis2-devs More help :
> https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help : https://help.launchpad.net/ListHelp
>
>
Follow ups
References
-
Web API - Search by id
From: Saptarshi Purkayastha, 2013-11-04
-
Re: Web API - Search by id
From: Jan Henrik Øverland, 2013-11-04
-
Re: Web API - Search by id
From: Saptarshi Purkayastha, 2013-11-04
-
Re: Web API - Search by id
From: Jan Henrik Øverland, 2013-11-04
-
Re: Web API - Search by id
From: Saptarshi Purkayastha, 2013-11-04
-
Re: Web API - Search by id
From: Brajesh Murari, 2013-11-04
-
Re: Web API - Search by id
From: Lars Kristian Roland, 2013-11-04
-
Re: Web API - Search by id
From: Murod Latifov, 2013-11-04
-
Re: Web API - Search by id
From: Brajesh Murari, 2013-11-04
-
Re: Web API - Search by id
From: Saptarshi Purkayastha, 2013-11-04