Actually with the new version 2.0 I would also change my workflow.
Version 1.2 had not online spec editor tooling support and this is why I
let Gemstone describe my REST API and render the Swagger json specification.
In Swagger 2.0 I would rather take the online spec editor define a
swagger spec and take the resulting json file to generate ZincRESTCall
subclasses.
This way a client developer or user is able to define his or her needs.
Whish I had more time right now.
Sebastian
Am 24.06.2015 um 01:14 schrieb itli...@schrievkrom.de:
We go a very similiar way as Sebastian - but with our company need NOT
to build a Smalltalk-only system, but also offer support for several
other developers/languages.
We use
* Zinc REST
* Gemstone 3.2.6
We generate code to have:
* Swagger-UI and Swagger-Core support (currently 1.2)
Earlier the swagger stuff was also handled by Gemstone, but now we
create Gemstone-Code to write the Swagger-specs into the server filesystem.
Practically the swagger-core support has been working with C# (we had to
correct/change the template for source code generation).
We see now the need to go to Swagger 2.0, to stay near the development
master stream.
The whole system is working very stable - the only problem I have is a
10 MB limit on the Gemstone socket system - here the Zinc HTTP System
subsystem must be changed to get rid of this problem.
Marten
Am 23.06.2015 um 20:40 schrieb sergio_101:
I have been a project coming up that I really onlyneed a restful API on.
The front end will be first built on a mobile device(iOS )then back on
possibly android, with a very stripped down web application.
i would like to use pharo/gemstones as the database.
is there a project out there that allows for such restful API
development in pharo land? This would be so fun!
thanks
