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]<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
