This assumes that the outputs of GETs can be used as is. But that's not particularly true with OpenMRS. In any GET, you are going to receive a lot of ref references, at least some of which will have to be expanded through individual GETs to the referenced objects. Think how you would populate a table of Patient ID, Patient Name, Village, Sex, DOB, Father/Husband Name, Caste and a link. For that case, I think an unadorned list is more useful. Of course, the alternative is custom "representations" (quotes because they may not be congruent with the definition of representation) which would expand certain fields. A full, unadorned list is also better for populating dropdowns. As I said, I don't mind having start and count parameters; I definitely wouldn't mind having some sort of standard parameters for selecting a range of IDs, names, dates.
From: [email protected] [mailto:[email protected]] On Behalf Of Saptarshi Purkayastha Sent: Wednesday, February 22, 2012 1:57 PM To: [email protected] Subject: Re: [OPENMRS-DEV] Feedback on OpenMRS REST web service module Roger, Most REST APIs have the paging feature to be able to restrict the amount of data that a client is able to process. This I think is appropriate given that we don't want the client to act as another service provider and instead be limited to what they are looking for. Facebook for example gives out previous and next page links on /posts or /searchresults. Twitter on the other hand gives only the first 100 list, but then the user gets the last id and looks for the next 100 manually. Either ways, an API IMO, when returning (or expecting to return) a long list, should make it easy for the client to allow viewing data through pages. Thus, I agree with Darius that the getAll should return a similar paging list that the search returns. PS: A facebook-esque until, since query is nice for encounter list or probably any other resources as well. --- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 22 February 2012 23:52, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: Darius -- I don't see why the responsibility for paging has been put on the API. If you want to have begin and count parameters on the get call, fine. But I think the return should always be a simple list. Saludos, Roger From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Saptarshi Purkayastha Sent: Wednesday, February 22, 2012 1:04 AM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] Feedback on OpenMRS REST web service module I agree... We should have those as common. @Ben: Nope I was on the road most of last week. Haven't created tickets for those --- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 22 February 2012 04:13, Darius Jazayeri <[email protected]<mailto:djazayeri%[email protected]>> wrote: One thing I just noticed is that we're being inconsistant in how we treat getAll and search and (I think ) this is a problem. GET .../concept?q=weight -> I get back an object with a "results" property (that's a list) and a a links" property (including a hyperlink to the next page of results). GET .../concept -> gets back just a plain list of all results. I propose that we change getAll so it behaves the same way as doing search(*). -Darius On Fri, Feb 17, 2012 at 7:15 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: Darius -- Here's a few points off the top of my head: 1. It's not clear how to create relationships. (a) In a straight parent-child relationship, is it enough to post to the child object, or do you also/instead need to update the child object collection of the parent. (b) In an optional one-to-many relationship between two full-fledged objects, can you just specify the partner in one of the objects' collections or both? (c) In a many-to-many relationship, can you just specify the partner in one of the objects' collections or both? 2. If we are going to comply with the principle that each object is available at one and only one URL, then we have to make the core object services extensible for additional searches and/or methods. It's probably also true that modules extending the API should be extensible in the same way. OK to limit to read only. 3. The Maven archetype changes have made it non-trivial to reference the web services module. Perhaps this is a not the fault of the web services module, but it is still in flux and potentially complicated by different relations between Maven and git than Maven and mvn. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Darius Jazayeri Sent: Thursday, February 09, 2012 9:19 PM To: [email protected]<mailto:[email protected]> Subject: [OPENMRS-DEV] Feedback on OpenMRS REST web service module To anyone who has used the OpenMRS REST Web Service module, We're very excited to have done a pre-release of our REST web service module last year, and really interested to learn about the ways people are using it, and how it's working for them. When we did the pre-release of the module, we intentionally called it version 0.8. We're new to the web service game, and we want to make sure we've gotten the API right, before we commit to supporting it as-is in the long term. So, now that quite a few months have passed since the pre-release, and I know some of you have made heavy use of the system, we'd really appreciate your answers to some questions: * Does the web service API give you access to the functionality you need? * Does it behave the way you want and expect it to? * Were you able to get up and running relatively quickly, with the existing documentation? * Does the API look like what you'd like us to release as "1.0", and support in the long run? -Darius, and the OpenMRS team ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
