[openstack-dev] [pecan] [WSME] Different content-type in request and response

Doug Hellmann doug at doughellmann.com
Wed Nov 26 15:18:40 UTC 2014


On Nov 26, 2014, at 3:49 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:

> Hi,
> 
> I traced the WSME code and found a place [0] where it tries to get arguments from request body based on different mimetype. So looks like WSME supports only json, xml and “application/x-www-form-urlencoded”.
> 
> So my question is: Can we fix WSME to also support “text/plain” mimetype? I think the first snippet that Nikolay provided is valid from WSME standpoint.

WSME is intended for building APIs with structured arguments. It seems like the case of wanting to use text/plain for a single input string argument just hasn’t come up before, so this may be a new feature.

How many different API calls do you have that will look like this? Would this be the only one in the API? Would it make sense to consistently use JSON, even though you only need a single string argument in this case?

> 
> Or if we don’t understand something in WSME philosophy then it’d nice to hear some explanations from WSME team. Will appreciate that.
> 
> 
> Another issue that previously came across is that if we use WSME then we can’t pass arbitrary set of parameters in a url query string, as I understand they should always correspond to WSME resource structure. So, in fact, we can’t have any dynamic parameters. In our particular use case it’s very inconvenient. Hoping you could also provide some info about that: how it can be achieved or if we can just fix it.

Ceilometer uses an array of query arguments to allow an arbitrary number.

On the other hand, it sounds like perhaps your desired API may be easier to implement using some of the other tools being used, such as JSONSchema. Are you extending an existing API or building something completely new?

Doug

> 
> If you need help with contribution let us know pls.
> 
> Thanks
> 
> [0] https://github.com/stackforge/wsme/blob/master/wsme/rest/args.py#L215
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> 
> 
>> On 25 Nov 2014, at 23:06, Nikolay Makhotkin <nmakhotkin at mirantis.com> wrote:
>> 
>> Hi, folks! 
>> 
>> I try to create a controller which should receive one http content-type in request but it should be another content-type in response. I tried to use pecan and wsme decorators for controller's methods.
>> 
>> I just want to receive text on server and send json-encoded string from server (request has text/plain and response - application/json) 
>> 
>> I tried: 
>> 
>> class MyResource(resource.Resource):
>>     id = wtypes.text
>>     name = wtypes.text
>> 
>> 
>> class MyResourcesController(rest.RestController):
>>     @wsexpose(MyResource, body=wtypes.text)
>>     def put(self, text):
>>         return MyResource(id='1', name=text)
>> 
>> 
>> According to WSME documentation (http://wsme.readthedocs.org/en/latest/integrate.html#module-wsmeext.pecan) signature wsexpose method as following: 
>> 
>>   wsexpose(return_type, *arg_types, **options)
>> 
>> Ok, I just set MyResource as return_type and body to text type. But it didn't work as expected: 
>> http://paste.openstack.org/show/138268/ 
>> 
>> I looked at pecan documentation at https://media.readthedocs.org/pdf/pecan/latest/pecan.pdf but I didn't find anything that can fit to my case.
>> 
>> Also, I tried: 
>> 
>> class MyResource(resource.Resource):
>>     id = wtypes.text
>>     name = wtypes.text
>> 
>> 
>> class MyResourcesController(rest.RestController):
>>     @expose('json')
>>     @expose(content_type="text/plain")
>>     def put(self):
>>         text = pecan.request.text
>>         return MyResource(id='1', name=text).to_dict()
>> 
>> It worked just in case if request and response have the same content-type. (application/json<->application/json, text/plain<->text/plain)
>> 
>> I also tried a lot of combination of parameters but it is still not worked.
>> 
>> Does anyone know what the problem is?
>> How it can be done using WSME and/or Pecan?
>> 
>> Sorry if I misunderstand something.
>> -- 
>> Best Regards,
>> Nikolay
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141126/1631a5aa/attachment.html>


More information about the OpenStack-dev mailing list