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].
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].
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.
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
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.
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.
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.
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....@gmail.com>
An: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>
Betreff: [Pharo-users] Repeateble URLs - REST?
Von: "sergio ruiz" <sergio....@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:
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
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
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101