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]> 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]] *On Behalf Of *Saptarshi > Purkayastha > *Sent:* Wednesday, February 22, 2012 1:04 AM > *To:* [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]> > 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]> 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]] *On Behalf Of *Darius > Jazayeri > *Sent:* Thursday, February 09, 2012 9:19 PM > *To:* [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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
