I would defer to Seaside experts on this, but I would say yes to Seaside REST in general and Teapot REST otherwise if it meets your requirements . I have not worked on them for a long time now. On Mon, Feb 25, 2019 at 2:05 PM sergio ruiz <sergio.rrd@gmail.com> wrote:

Gotcha..

So, in Seaside, should how should I handle the routes? with Seaside REST?

On February 25, 2019 at 2:56:49 PM, S Krish ( krishnamachari.sudhakar@gmail.com) wrote:

https://restfulapi.net/resource-naming/ <https://restfulapi.net/resource-naming/>

https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-desig...

Given the conflicting advices on REST, you can try and adhere to one-two sources of advice.

---- peace, sergio photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

I fully agree with everything Torsten said, but I would like to add a couple of points. It is very easy to add a couple of readable/shareable URL to a classic Seaside app. Here is a simple example: https://audio359.eu/ss/audio359-store?showSKU=sku0101 This jumps right into a web store written in Seaside/Bootstrap (this is #initialRequest: handling special arguments). People also overestimate their need to scale: you can get very far with a classic Seaside app, you just have to know what you are doing. The chance that you will have 1000s or even 100s of (concurrent) users is very small - in B2B even less so. Also, perfect horizontal linear scaling of http web apps does not exist in practice (unless for very simple applications). 9 times out of 10, your users will have to log in, will have preferences/settings, unfinished data structures (shopping cart, ..), and more. All this constitutes your session state. This state must be shared between all workers, which is the big problem. And your web app workers will most probably need to access some shared database as well, which can be a bottleneck as well. You can quite easily scale Seaside using session affinity: your load balancer sends each request from the same client back to the same worker, where its state lives. Hence no need for complex session sharing. When a worker crashes, the client has to log in again and connect to a new worker. You can augment this with minimal session sharing (for example in memcached), so that at least the login and maybe some other essential information is preserved. I have a couple of responsive mobile web apps written with classic Seaside/Bootstrap that perform very well, IMHO. The trick is to make you app fast and do as little work as possible on each interaction. Client side, javascript based web apps are way more complicated, IMO.

On 28 Feb 2019, at 10:04, Torsten Bergmann <astares@gmx.de> wrote:

Hi sergio,

I like that http://www.bagelconcertfinder.com uses Seaside and also my Twitter Bootstrap Library.

Seaside by default works with stateful (web) components - making it easy to develop - but possibly hard to scale to be the next Twitter, Amazon, ... ;)

Seaside usually renders the page on the server and sends the HTML to the client similar to other "old style" web frameworks like JSF who work with server side rendering. But Seaside also supports building a stateless REST interface using the "Seaside-REST" package [1].

Statelessness can help in scaling an APIs to millions of concurrent users - that's why REST is so popular these days. Another reason is that within a web browser you can do more and more work locally - so it is often appropriate to use a client side framework and talk to a (REST) API on the server.

Also a REST interface could open up your application functionality not only to users but also to other software for public consumption or composing different application functionality into a common usable service.

One style you can provide it to use the same URL as your HTML interface - so depending on the mime type requested in the REQUEST HEADER for a GET the

<SERVER URL>/zipcode/44805

could provide either HTML (for a browser) or a JSON (for consumption via an application). This might make sense for data driven pages with a clear boundary on the data provided and often for data that could be fetched without any authentication or other.

Often it is better to provide a specific API on a different URL - as this allows to provide authentication to your service and a workflow like style (login on the API, get or put some data on the server or trigger functionality). Also you can version your exposed API if required.

Basically you can use whatever backend technology to build your service and expose it via such a REST API. If you use Pharo and want to provide a "stateless" server interface you can start as many images as you like and scale out with a load balancer in front.

If you want to have an easy way to do REST with Pharo (without any Seaside magic) then check out the docu and the example on my Tealigh GitHub project on [2]. Tealight is a lightweight project on top of Teapot to experiment and quickly build a REST interface using pragmas on methods. It is simple to use and you can build an interface in a few minutes only with the help of Zinc and Teapot/Tealight.

Also data is usually exchanged using JSON - so Svens NeoJSON for Pharo [3] is something to look at.

If you work with stateless sessions then often you require a token exchange, so not every call requires a second authentication. This is usually done using JSON Web Tokens (JWT) and there is a Pharo project for that as well [4].

Hope this helps a little bit moving forward.

Regards Torsten (aka "astares")

[1] http://book.seaside.st/book/advanced/restful [2] https://github.com/astares/Tealight [3] https://github.com/svenvc/NeoJSON [4] https://github.com/noha/JSONWebToken

Gesendet: Montag, 25. Februar 2019 um 19:12 Uhr Von: "sergio ruiz" <sergio.rrd@gmail.com> An: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> Betreff: [Pharo-users] Repeateble URLs - REST? Hi, all..

I am looking to have a repeatable url so users can save them and share them.. something like:

www.bagelconcertfinder.com/zipcode/44805

and in my next project, I’ll be doing something like a CMS where you would get:

/blog_entries/this-is-the-path

I am thinking of using REST to flesh out the paths..

does this seem reasonable?

---- peace, sergio photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101