Re: [openstack-dev] [pecan] [WSME] Different content-type in request and response
On Dec 18, 2014, at 2:53 AM, Renat Akhmerov 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
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
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
Re: [openstack-dev] [pecan] [WSME] Different content-type in request and response
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
Re: [openstack-dev] [pecan] [WSME] Different content-type in request and response
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.
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
mailto:d...@doughellmann.com wrote:
On Nov 26, 2014, at 3:49 AM, Renat Akhmerov rakhme...@mirantis.com
mailto: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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pecan] [WSME] Different content-type in request and response
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:
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pecan] [WSME] Different content-type in request and response
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.
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.
If you need help with contribution let us know pls.
Thanks
[0] https://github.com/stackforge/wsme/blob/master/wsme/rest/args.py#L215
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 nmakhot...@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
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/
http://paste.openstack.org/show/138268/
I looked at pecan documentation at
https://media.readthedocs.org/pdf/pecan/latest/pecan.pdf
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@lists.openstack.org
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
Re: [openstack-dev] [pecan] [WSME] Different content-type in request and response
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?
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 nmakhot...@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@lists.openstack.org
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
