REST Web services - Ease of Use and Commonalities

classic Classic list List threaded Threaded
4 messages Options
sunbiz sunbiz
Reply | Threaded
Open this post in threaded view
|

REST Web services - Ease of Use and Commonalities

I am trying to post the following to create a person...

{
 "names": [{"givenName": "Test", "familyName": "Woman"}],
 "gender": "F",
 "age": 32,
 "birthdate": "1980-01-02",
 "birthdateEstimated": true,
 "dead": true,
 "deathDate": "2012-05-05",
 "causeOfDeath": "Cancer",
 "addresses": [{"preferred":true,"address1": "12 Hauz Khas Village", "address2": "Hauz Khas", "city": "New Delhi", "postalCode": "110011"}],
 "attributes": [{"8d871f2a-c2cc-11de-8d13-0010c6dffd0f":"Married", "8d871afc-c2cc-11de-8d13-0010c6dffd0f": "Indian"}]
}

There is some problem with the documentation here or probably a bug... So although *age* is a creatable property according to the documentation, I cannot create a person with age
The names is nice because we do not have to call the personname resource and create a name. Though, I wonder why addresses can't be done in the same way.

Attributes might be a little complex, but shouldn't they be done in a similar fashion...  So, 8d871f2a-c2cc-11de-8d13-0010c6dffd0f is Civil Status (attribute type) and I'm trying to save the value of Married to create a new atttribute for that person.

Is there a notion by which we can write/distinguish in the documentation as to what sub-resources can be created on the fly, while others need to be created separately and referenced??

---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: REST Web services - Ease of Use and Commonalities

Hi Saptarshi,

If you can't create someone with just Age, that's a bug and you should file a ticket.

Addresses should work the same as names, i.e. they should be creatable when the person is created. If that's not supported, ticket that too.

I would expect attributes to work like:

attributes: [
  { attributeType: "uuid-of-civil-status", value: "uuid-of-Married-concept" },
  { attributeType: "uuid-of-nationality", value: "Indian assuming free-text" }
]

This is more in line with the way they are represented when you GET a person, i.e. it's a list of attributes, not a list of map entries.

The notion is that the parent resource lists in its "creatable properties" any sub-resources that can be created at its creation-time. Does our documentation actually show sub-resources as part of the owning resources? (It should, but I don't remember whether we coded this...)

-Darius

On Sat, May 5, 2012 at 4:31 AM, Saptarshi Purkayastha <[hidden email]> wrote:
I am trying to post the following to create a person...

{
 "names": [{"givenName": "Test", "familyName": "Woman"}],
 "gender": "F",
 "age": 32,
 "birthdate": "1980-01-02",
 "birthdateEstimated": true,
 "dead": true,
 "deathDate": "2012-05-05",
 "causeOfDeath": "Cancer",
 "addresses": [{"preferred":true,"address1": "12 Hauz Khas Village", "address2": "Hauz Khas", "city": "New Delhi", "postalCode": "110011"}],
 "attributes": [{"8d871f2a-c2cc-11de-8d13-0010c6dffd0f":"Married", "8d871afc-c2cc-11de-8d13-0010c6dffd0f": "Indian"}]
}

There is some problem with the documentation here or probably a bug... So although *age* is a creatable property according to the documentation, I cannot create a person with age
The names is nice because we do not have to call the personname resource and create a name. Though, I wonder why addresses can't be done in the same way.

Attributes might be a little complex, but shouldn't they be done in a similar fashion...  So, 8d871f2a-c2cc-11de-8d13-0010c6dffd0f is Civil Status (attribute type) and I'm trying to save the value of Married to create a new atttribute for that person.

Is there a notion by which we can write/distinguish in the documentation as to what sub-resources can be created on the fly, while others need to be created separately and referenced??

---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
sunbiz sunbiz
Reply | Threaded
Open this post in threaded view
|

Re: REST Web services - Ease of Use and Commonalities

Hi Darius,

Created a bug for age: https://tickets.openmrs.org/browse/RESTWS-252

addresses is actually working fine, I was using the property incorrectly naming it city instead of cityVillage... although the error could have been better saying that there is no property called cityVillage instead of saying ConversionException - cannot convert object...

attributes isn't working as you mentioned. Get the following exception:

"message": "Unable to convert object into response content",
"code": "org.openmrs.module.webservices.rest.web.resource.impl.BaseDelegatingResource:579",
"detail": "org.openmrs.module.webservices.rest.web.response.ConversionException: activeAttributes on class org.openmrs.Person
  at org.openmrs.module.webservices.rest.web.resource.impl.BaseDelegatingResource.setProperty(BaseDelegatingResource.java:579)
  at org.openmrs.module.webservices.rest.web.resource.impl.BaseDelegatingResource.setConvertedProperties(BaseDelegatingResource.java:446)
  at org.openmrs.module.webservices.rest.web.resource.impl.DelegatingCrudResource.create(DelegatingCrudResource.java:93)
  at org.openmrs.module.webservices.rest.web.v1_0.controller.BaseCrudController.create(BaseCrudController.java:83)
  at sun.reflect.GeneratedMethodAccessor1051.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)\n\tat java.lang.reflect.Method.invoke(Method.java:597)...


---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE


On 7 May 2012 00:49, Darius Jazayeri <[hidden email]> wrote:
>
> Hi Saptarshi,
>
> If you can't create someone with just Age, that's a bug and you should file a ticket.
>
> Addresses should work the same as names, i.e. they should be creatable when the person is created. If that's not supported, ticket that too.
>
> I would expect attributes to work like:
>
> attributes: [
>   { attributeType: "uuid-of-civil-status", value: "uuid-of-Married-concept" },
>   { attributeType: "uuid-of-nationality", value: "Indian assuming free-text" }
> ]
>
> This is more in line with the way they are represented when you GET a person, i.e. it's a list of attributes, not a list of map entries.
>
> The notion is that the parent resource lists in its "creatable properties" any sub-resources that can be created at its creation-time. Does our documentation actually show sub-resources as part of the owning resources? (It should, but I don't remember whether we coded this...)
>
> -Darius
>
> On Sat, May 5, 2012 at 4:31 AM, Saptarshi Purkayastha <[hidden email]> wrote:
>>
>> I am trying to post the following to create a person...
>>
>> {
>>  "names": [{"givenName": "Test", "familyName": "Woman"}],
>>  "gender": "F",
>>  "age": 32,
>>  "birthdate": "1980-01-02",
>>  "birthdateEstimated": true,
>>  "dead": true,
>>  "deathDate": "2012-05-05",
>>  "causeOfDeath": "Cancer",
>>  "addresses": [{"preferred":true,"address1": "12 Hauz Khas Village", "address2": "Hauz Khas", "city": "New Delhi", "postalCode": "110011"}],
>>  "attributes": [{"8d871f2a-c2cc-11de-8d13-0010c6dffd0f":"Married", "8d871afc-c2cc-11de-8d13-0010c6dffd0f": "Indian"}]
>> }
>>
>> There is some problem with the documentation here or probably a bug... So although *age* is a creatable property according to the documentation, I cannot create a person with age
>> The names is nice because we do not have to call the personname resource and create a name. Though, I wonder why addresses can't be done in the same way.
>>
>> Attributes might be a little complex, but shouldn't they be done in a similar fashion...  So, 8d871f2a-c2cc-11de-8d13-0010c6dffd0f is Civil Status (attribute type) and I'm trying to save the value of Married to create a new atttribute for that person.
>>
>> Is there a notion by which we can write/distinguish in the documentation as to what sub-resources can be created on the fly, while others need to be created separately and referenced??
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>> You Live by CHOICE, Not by CHANCE
>> ________________________________
>> Click here to unsubscribe from OpenMRS Developers' mailing list
>
>
[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: REST Web services - Ease of Use and Commonalities

Hi Saptarshi,

Sounds like a ticketable bug too. It'd be helpful to see the caused-by of that exception...

-Darius

On Mon, May 7, 2012 at 3:52 AM, Saptarshi Purkayastha <[hidden email]> wrote:
Hi Darius,

Created a bug for age: https://tickets.openmrs.org/browse/RESTWS-252

addresses is actually working fine, I was using the property incorrectly naming it city instead of cityVillage... although the error could have been better saying that there is no property called cityVillage instead of saying ConversionException - cannot convert object...

attributes isn't working as you mentioned. Get the following exception:

"message": "Unable to convert object into response content",
"code": "org.openmrs.module.webservices.rest.web.resource.impl.BaseDelegatingResource:579",
"detail": "org.openmrs.module.webservices.rest.web.response.ConversionException: activeAttributes on class org.openmrs.Person
  at org.openmrs.module.webservices.rest.web.resource.impl.BaseDelegatingResource.setProperty(BaseDelegatingResource.java:579)
  at org.openmrs.module.webservices.rest.web.resource.impl.BaseDelegatingResource.setConvertedProperties(BaseDelegatingResource.java:446)
  at org.openmrs.module.webservices.rest.web.resource.impl.DelegatingCrudResource.create(DelegatingCrudResource.java:93)
  at org.openmrs.module.webservices.rest.web.v1_0.controller.BaseCrudController.create(BaseCrudController.java:83)
  at sun.reflect.GeneratedMethodAccessor1051.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)\n\tat java.lang.reflect.Method.invoke(Method.java:597)...


---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE


On 7 May 2012 00:49, Darius Jazayeri <[hidden email]> wrote:
>
> Hi Saptarshi,
>
> If you can't create someone with just Age, that's a bug and you should file a ticket.
>
> Addresses should work the same as names, i.e. they should be creatable when the person is created. If that's not supported, ticket that too.
>
> I would expect attributes to work like:
>
> attributes: [
>   { attributeType: "uuid-of-civil-status", value: "uuid-of-Married-concept" },
>   { attributeType: "uuid-of-nationality", value: "Indian assuming free-text" }
> ]
>
> This is more in line with the way they are represented when you GET a person, i.e. it's a list of attributes, not a list of map entries.
>
> The notion is that the parent resource lists in its "creatable properties" any sub-resources that can be created at its creation-time. Does our documentation actually show sub-resources as part of the owning resources? (It should, but I don't remember whether we coded this...)
>
> -Darius
>
> On Sat, May 5, 2012 at 4:31 AM, Saptarshi Purkayastha <[hidden email]> wrote:
>>
>> I am trying to post the following to create a person...
>>
>> {
>>  "names": [{"givenName": "Test", "familyName": "Woman"}],
>>  "gender": "F",
>>  "age": 32,
>>  "birthdate": "1980-01-02",
>>  "birthdateEstimated": true,
>>  "dead": true,
>>  "deathDate": "2012-05-05",
>>  "causeOfDeath": "Cancer",
>>  "addresses": [{"preferred":true,"address1": "12 Hauz Khas Village", "address2": "Hauz Khas", "city": "New Delhi", "postalCode": "110011"}],
>>  "attributes": [{"8d871f2a-c2cc-11de-8d13-0010c6dffd0f":"Married", "8d871afc-c2cc-11de-8d13-0010c6dffd0f": "Indian"}]
>> }
>>
>> There is some problem with the documentation here or probably a bug... So although *age* is a creatable property according to the documentation, I cannot create a person with age
>> The names is nice because we do not have to call the personname resource and create a name. Though, I wonder why addresses can't be done in the same way.
>>
>> Attributes might be a little complex, but shouldn't they be done in a similar fashion...  So, 8d871f2a-c2cc-11de-8d13-0010c6dffd0f is Civil Status (attribute type) and I'm trying to save the value of Married to create a new atttribute for that person.
>>
>> Is there a notion by which we can write/distinguish in the documentation as to what sub-resources can be created on the fly, while others need to be created separately and referenced??
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>> You Live by CHOICE, Not by CHANCE
>> ________________________________
>> Click here to unsubscribe from OpenMRS Developers' mailing list
>
>
[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list