Ok, Doug, we’ll look into it. Thanks
Renat Akhmerov @ Mirantis Inc. > On 18 Dec 2014, at 22:59, Doug Hellmann <[email protected]> wrote: > > > On Dec 18, 2014, at 2:53 AM, Renat Akhmerov <[email protected] > <mailto:[email protected]>> 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 <[email protected]> wrote: >>> >>> Doug, thanks for your answer! >>> >>> My explanations below.. >>> >>> >>>> On 26 Nov 2014, at 21:18, Doug Hellmann <[email protected]> wrote: >>>> >>>> >>>> On Nov 26, 2014, at 3:49 AM, Renat Akhmerov <[email protected]> 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 >> [email protected] <mailto:[email protected]> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
