Repeateble URLs - REST?
Locked
 
|
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 Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 |
|
|
This is fine: <a href="http://www.bagelconcertfinder.com/zipcodes/{zipCode}">www.bagelconcertfinder.com/zipcodes/{zipCode} Preferred is : https://......siteName.../boundedContext/resourceInPlural/{resourceId} So this can be as you state but without _ underscores and "concertBlogging" is identified bounded context for a set of resources https://....siteName../concertBlogging/blogs/{blogId} Plurals are recommended. Lots of Style conformance is recommended, stick to REST and not use actions/ verbs in urls et als.. You can break many of the so called rules and still it will work fine for you, but its up to you, to decide what you adhere to and what you define for yourself Given the conflicting advices on REST, you can try and adhere to one-two sources of advice. On Mon, Feb 25, 2019 at 12:13 PM sergio ruiz <[hidden email]> 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 ([hidden email]) wrote:
---- 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 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 <[hidden email]> wrote:
|
|
|
In reply to this post by sergio_101
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]. 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" <[hidden email]> An: "Any question about pharo is welcome" <[hidden email]> 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 Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 |
Re: Repeateble URLs - REST?
|
|
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 <[hidden email]> 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" <[hidden email]> > An: "Any question about pharo is welcome" <[hidden email]> > 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 |
|
|
In reply to this post by Torsten Bergmann
Thanks so much for your library! I have built several applications in seaside, and always dig using it.. it’s my go to framework when I do a project on my own..
most everything I work on will never be the next twitter or amazon.. so i am fine tweaking here or there.. I have thought about doing exactly what you are talking about.. In my day job, we use LOTS of Angular. I thought about setting up a REST interface using Teapot, and using angular for the web part.. This provides for a much more interactive user experience, but I also totally love how seaside works.. Maybe for my CMS type project, I’ll use Teapot/Angular.. I will have to think about this for a bit… I did a project last year where I used teapot in conjunction with an SMS interface to create a very useful bot.. This was incredibly handy.. ---- 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 |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |