Ok, Doug, we’ll look into it.

Thanks

Renat Akhmerov
@ Mirantis Inc.



> On 18 Dec 2014, at 22:59, Doug Hellmann <d...@doughellmann.com> wrote:
> 
> 
> On Dec 18, 2014, at 2:53 AM, Renat Akhmerov <rakhme...@mirantis.com 
> <mailto:rakhme...@mirantis.com>> wrote:
> 
>> Doug,
>> 
>> Sorry for trying to resurrect this thread again. It seems to be pretty 
>> important for us. Do you have some comments on that? Or if you need more 
>> context please also let us know.
> 
> WSME has separate handlers for JSON and XML now. You could look into adding 
> one for YAML. I think you’d want to start looking in 
> http://git.openstack.org/cgit/stackforge/wsme/tree/wsme/rest 
> <http://git.openstack.org/cgit/stackforge/wsme/tree/wsme/rest>
> 
> By default WSME is going to want to encode the response in the same format as 
> the inputs, because it’s going to expect the clients to want that. I’m not 
> sure how hard it would be to change that assumption, or whether the other 
> WSME developers would really think it’s a good idea.
> 
> Doug
> 
>> 
>> Thanks
>> 
>> Renat Akhmerov
>> @ Mirantis Inc.
>> 
>> 
>> 
>>> On 27 Nov 2014, at 17:43, Renat Akhmerov <rakhme...@mirantis.com> wrote:
>>> 
>>> Doug, thanks for your answer! 
>>> 
>>> My explanations below..
>>> 
>>> 
>>>> On 26 Nov 2014, at 21:18, Doug Hellmann <d...@doughellmann.com> wrote:
>>>> 
>>>> 
>>>> On Nov 26, 2014, at 3:49 AM, Renat Akhmerov <rakhme...@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?
>>> 
>>> We have 5-6 API calls where we need it.
>>> 
>>> And let me briefly explain the context. In Mistral we have a language (we 
>>> call it DSL) to describe different object types: workflows, workbooks, 
>>> actions. So currently when we upload say a workbook we run in a command 
>>> line:
>>> 
>>> mistral workbook-create my_wb.yaml
>>> 
>>> where my_wb.yaml contains that DSL. The result is a table representation of 
>>> actually create server side workbook. From technical perspective we now 
>>> have:
>>> 
>>> Request:
>>> 
>>> POST /mistral_url/workbooks
>>> 
>>> {
>>>  “definition”: “escaped content of my_wb.yaml"
>>> }
>>> 
>>> Response:
>>> 
>>> {
>>>  “id”: “1-2-3-4”,
>>>  “name”: “my_wb_name”,
>>>  “description”: “my workbook”,
>>>  ...
>>> }
>>> 
>>> The point is that if we use, for example, something like “curl” we every 
>>> time have to obtain that “escaped content of my_wb.yaml” and create that, 
>>> in fact, synthetic JSON to be able to send it to the server side.
>>> 
>>> So for us it would be much more convenient if we could just send a plain 
>>> text but still be able to receive a JSON as response. I personally don’t 
>>> want to use some other technology because generally WSME does it job and I 
>>> like this concept of rest resources defined as classes. If it supported 
>>> text/plain it would be just the best fit for us.
>>> 
>>>>> 
>>>>> 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?
>>> 
>>> We want to improve our existing Mistral API. Basically, the idea is to be 
>>> able to apply dynamic filters when we’re requesting a collection of objects 
>>> using url query string. Yes, we could use JSONSchema if you say it’s 
>>> absolutely impossible to do and doesn’t follow WSME concepts, that’s fine. 
>>> But like I said generally I like the approach that WSME takes and don’t 
>>> feel like jumping to another technology just because of this issue.
>>> 
>>> Thanks for mentioning Ceilometer, we’ll look at it and see if that works 
>>> for us.
>>> 
>>> Renat
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to