[Glass] Getting started with REST

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Zinc-Rest is the way to go and then Neo-JSON.


Marten

--
Marten Feldtmann
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Thierry,

Both Seaside-REST and Zinc-REST are viable options. We have a Seaside-REST service (using Seaside 3.0.10) running in production and I have been playing with Zinc-REST services in development too.
I think it depends on what you feel most comfortable with.

Seaside-REST doc: [3]
Zinc-REST doc: [4]

For the latest Seaside 3.1 port, see [1]. This one is entirely in sync with the Pharo/Squeak base version.
For the latest working Zinc port, see [2]. This one corresponds to version 2.3.2 of Zinc on Pharo.

I have been working on updating the Zinc port to the latest version [5] but got a bit entrenched because more recent versions have changes to the encoding implementation, which is a part where many subtle differences can be found between Pharo and Gemstone. So, for now the Zinc port on Gemstone is lagging behind the Pharo version.

In both cases, I am interested to get feedback on problems so I can improve the ported implementations.

regards
Johan

[1] https://github.com/glassdb/Seaside31/tree/gemstone3.1
[2] https://github.com/glassdb/zinc/tree/gemstone3.1
[3] https://code.google.com/p/seaside/wiki/SeasideRest
[4] http://zn.stfx.eu/zn/zinc-http-components-paper.html
[5] https://github.com/jbrichau/zinc/commits/gemstone2.4

On 19 Mar 2014, at 23:24, Thierry Thelliez <[hidden email]> wrote:

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Wed, Mar 19, 2014 at 11:24 PM, Thierry Thelliez
<[hidden email]> wrote:
I'm obviously biased and don't know Zinc-REST well so reader
discretion is advised.

What Seaside-REST has going for it:
First it works more or less everywhere where Seaside runs. This isn't
strictly true - it requires pragmas. It is not (yet?) common for
Smalltalk libraries to build on pragmas (Magritte and OB come to
mind). Initially pragmas were optional but they proved much more
powerful so now we require them. This makes Seaside-REST feel similar
to Java libraries like JAX-RS or Spring Web MVC (this is not a
coincidence).

Seaside-JSON builds on the same canvas classes as the HTML canvas.
This means it's possible to plug in "native accelerators" (we use
CharacterSet on Squeak/Pharo). Also when you have a server that does
buffer pooling you can greatly reduce your allocation rate.

The thing you may want consider no matter what you chose is
Magritte-JSON to do "automatic" data binding. Magritte is one of those
things once you understand it you solve everything with it.

I heard once of somebody working on a swagger binding for Seaside-REST
but haven't heard anything since. Maybe Johan knows more.

Keep in mind that in production you have to enable route caching for
Seaside-REST otherwise performance will suffer greatly.

Cheers
Philippe
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On 20 Mar 2014, at 14:21, Philippe Marschall <[hidden email]> wrote:

> I heard once of somebody working on a swagger binding for Seaside-REST
> but haven't heard anything since. Maybe Johan knows more.

Haha, yes that would be this one:

https://staging.yesplan.be/swagger/

This API documentation is generated automatically from the REST implementation.
If you want to know more what Swagger is: http://swagger.wordnik.com/

We did not really forget to release this publicly but our use of Seaside-REST has become more intricate. We don't directly use the pragmas anymore but actually generate the routes from an internal description of our API. Similarly, we have been extending the Swagger-UI app.

But yes, one I get back into the office (I'm on holidays), I will set up a plan to make it public.

cheers,
Johan
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Zinc_REST is a pretty stable stuff and I've found only two problems yet
under Gemstone:

* 10 MByte Socket problem - this is a limitation within Gemstone and the
reading service method within Zinc should consider this ...

* Zinc under Gemstone does not consider some GsSocket exceptions, which
under some circumstances crashes the server ...

Over all it does its work.

Just some comments why I did not use Seaside-REST:

I'm not considering using Seaside (application development) under
Gemstone, because I do not want to put too much work on the database -
considering the free version limitations.

Testing and documentation is done by using swagger - as mentioned on my
blog.

On the GUI side I'm now switching to Javascript and leave Seaside (which
I used to use under VASmalltalk).


Marten


Am 20.03.2014 08:44, schrieb Johan Brichau:

> In both cases, I am interested to get feedback on problems so I can improve the ported implementations.
>
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On 20 Mar 2014, at 16:19, [hidden email] wrote:

> * 10 MByte Socket problem - this is a limitation within Gemstone and the
> reading service method within Zinc should consider this ...
>
> * Zinc under Gemstone does not consider some GsSocket exceptions, which
> under some circumstances crashes the server ...

Thank you for reporting these.
I made issues on the tracker so they are not forgotten:

https://github.com/glassdb/zinc/issues/46
https://github.com/glassdb/zinc/issues/45

If you can provide some more info, then I hope we can address them soon!

Johan
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Am 19.03.2014 22:56, schrieb [hidden email]:
> Zinc-Rest is the way to go and then Neo-JSON.
>
>
> Marten
>
Same here! I also use NeoCSV for table like result data.

I find Seaside-REST provides a lot of overhead for a pure REST or HTTP
interface.

Sebastian
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Thu, Mar 20, 2014 at 4:19 PM, [hidden email]
<[hidden email]> wrote:
Seaside-REST builds only on the request, response and request handler
classes on Seaside. It does not use any sessions, continuations or
similar (as nothing that has REST in the name should). Seaside-REST
will not put anything into the database besides the request handlers
and that only initially on set up. A normal request will not put
anything into the database.

Cheers
Philippe
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Fri, Mar 21, 2014 at 2:28 AM, Sebastian Heidbrink
<[hidden email]> wrote:
What overhead are you talking about? In the end it's just request
handlers. As for the code it only depends on Seaside-Core.

Cheers
Philippe
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass