<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Doug,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""><div class="">
<div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 27 Nov 2014, at 17:43, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com" class="">rakhmerov@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div apple-content-edited="true" class=""><div class="">Doug, thanks for your answer! </div><div class=""><br class=""></div><div class="">My explanations below..</div><br class="Apple-interchange-newline">
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On 26 Nov 2014, at 21:18, Doug Hellmann <<a href="mailto:doug@doughellmann.com" class="">doug@doughellmann.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class="Apple-interchange-newline">On Nov 26, 2014, at 3:49 AM, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com" class="">rakhmerov@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Hi,</div><div class=""><br class=""></div>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”.<div class=""><br class=""></div><div class="">So my question is:<span class="Apple-converted-space"> </span><b class="">Can we fix WSME to also support “text/plain” mimetype?</b><span class="Apple-converted-space"> </span>I think the first snippet that Nikolay provided is valid from WSME standpoint.</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div></div></div></blockquote><div class=""><br class=""></div><div class="">We have 5-6 API calls where we need it.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">mistral workbook-create my_wb.yaml</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">Request:</div><div class=""><br class=""></div><div class="">POST /mistral_url/workbooks</div><div class=""><br class=""></div><div class="">{</div><div class=""> “definition”: “escaped content of my_wb.yaml"</div><div class="">}</div><div class=""><br class=""></div><div class=""><div class="">Response:</div><div class=""><br class=""></div><div class="">{</div><div class=""> “id”: “1-2-3-4”,</div><div class=""> “name”: “my_wb_name”,</div><div class=""> “description”: “my workbook”,</div><div class=""> ...</div><div class="">}</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Or if we don’t understand something in WSME philosophy then it’d nice to hear some explanations from WSME team. Will appreciate that.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">Ceilometer uses an array of query arguments to allow an arbitrary number.</div><div class=""><br class=""></div><div class="">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?</div></div></div></blockquote><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks for mentioning Ceilometer, we’ll look at it and see if that works for us.</div><div class=""><br class=""></div><div class="">Renat</div></div></div></blockquote></div><br class=""></div></body></html>