Hi Brian,
Ah, sorry for responding to quickly. I clearly missed your point.Indeed all the
$$xxx properties are not in the example response like you indicate.However, at
the moment I am not aware of the reason why it is implemented this way...(My
guess would be the different representation types)
Maybe somebody else has thoughts on this?
grtz Johan
On Thu, Aug 23, 2018 10:57 PM, Brian K [email protected] wrote:
Hi Johan,
Thanks for the reply. In using the REST API from a csharp application, I
want to be able to generate a client stub and code to that. This is what
Swagger Codegen is made for. For the Apache Isis REST implementation, I
notice the following:
1. All the domain object actions are represented by REST operations
that take the object's instanceId as the first argument. This is a string
that for an integer primary key is something like "i_1". I see this in the
REST response as either the property "$$instanceId" or the JSON property
"instanceId" above the "members" property.
2. This instanceId is not in the Swagger specification generated by
Isis. When I load the specification (from the prototyping menu) into
https://editor.swagger.io/, the response example it creates for the action
does not include the $$instanceId property that is there when I call that
endpoint on the Isis application. This is true for each schema I download
(public, private, private with prototyping).
Therefore, the client generated by codegen is not useable without falling
back to looking directly at the JSON of the REST operation response.
It may be a good idea to include the instanceId in the generated
specification so that these actions can be called from generated clients.
I could add a read-only property to return the instanceId, but I am hoping
there is a better way.
Thanks,
Brian
On Wed, Aug 22, 2018 at 10:48 PM Johan Doornenbal <[email protected]>
wrote:
Hi Brian,
The restful objects viewer implemented in Apache Isis and exposed by
swagger-ui
implements the restful objects spec 1)
The basic idea is that you can 'discover' the domain.In the case of simple
app:
you can start out with
curl -X GET --header 'Accept: application/json' --header 'Authorization:
Basic
c3ZlbjpwYXNz'
'[YOUR_BASE_URL]/restful/services/simple.SimpleObjectMenu/actions/listAll/invoke'
That will give you among others the oid's.
Then update name can be done by
curl -X PUT --header 'Content-Type: application/json' --header 'Accept:
application/json' --header 'Authorization: Basic c3ZlbjpwYXNz' -d '{ \
"name" :
{ \ "value" : "some new name" \ } \ }'
'[YOUR_BASE_URL]/restful/objects/simple.SimpleObject/0/actions/updateName/invoke'
Grtz Johan
1) http://isis.apache.org/guides/ugvro/ugvro.html#__ugvro
On Wed, Aug 22, 2018 11:15 PM, Brian K [email protected] wrote:
Hello,
I see by using the Swagger-UI that the REST view is usable by inspecting
the JSON. For instance, I can get an object via the GET url, and then
execute an action on it by looking at the "$$instanceId" member to fill in
the action string argument that is needed for its actions: "objectID".
But, swagger-codegen seems to ignore this attribute. Maybe it's because it
starts with $$ and is not a part of the generated swagger specification.
Using a generated client stub (I tried both "java" and "csharp"
generators), I don't see a way of finding out the objectID string needed to
execute the object's actions.
Has anyone been able to execute actions from a REST client generated by
swagger codegen? For instance, in SimpleApp archetype, can you execute the
UpdateName action of SimpleObject? Is there a basic piece I'm missing?
Thank you,
Brian
