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
> <mailto:rakhme...@mirantis.com>> wrote:
>> I traced the WSME code and found a place  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:
“definition”: “escaped content of my_wb.yaml"
“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.
OpenStack-dev mailing list