Thanks for the observation. In the age of text chats and SMS, not that I do either of them, we forget the art of writing well.
On Thu, Aug 28, 2014 at 2:34 PM, Ben Coman <b...@openinworld.com> wrote: > I haven't the time play with it right now, but its a good read. Just > some minor grammar feedback... > > > you are quicker off the block > you are quickly off the block > > > This also provides a flexibility in scaling > This also provides flexibility in scaling > > cheers -ben > > S Krish wrote: > > > The framework is nice.. and addictive to play with as stated before, well > documented, clean and easy.. ! > > Potentially a good tool to weave into any app. My quick play with the > framework, surprised me with its productive usage.. so here it goes.. > Teapot: Pharo web REST framework, it ain’t micro > <https://skrishnamachari.wordpress.com/2014/08/28/teapot-pharo-web-rest-framework-it-aint-micro/> > > > On Mon, Aug 25, 2014 at 11:06 PM, Attila Magyar <m.magy...@gmail.com> > wrote: > >> Santiago Bragagnolo wrote >> >> I played a little bit with Teapot last week during ESUG and was >> wondering >> >> what is your flow when you are designing/experimenting an API with >> >> Teapot? >> >> Do you reset the instance everytime you modify/add a route? >> >> I'm not sure i understand it correctly. The routes are stored in a >> router in >> an OrderedCollection. If you say >> >> teapot >> GET: '/foo/bar' -> someAction >> >> A new Route will be created with the given url pattern, action, http >> method >> and default response transformer. The first 3 things cannot be modifed >> later, but the response transformer can. So if you say: >> >> teapot >> GET: '/foo/bar' -> someAction; output: #ston >> >> Then the ston transformer will be added to the current route, after the >> route was added to the router. Teapot stores a reference to the current >> route to be able to do this. In the future there may be other messages >> (eg. >> filtering based on the content-type or other request properties). The >> reason >> for doing this is to avoid the combinatorial explosion of method numbers >> (there is no need to implement GET:output:, POST:output:, etc..). >> >> Is it an answer for your question or did you mean something else? >> >> >> >> -- >> View this message in context: >> http://forum.world.st/ANN-Teapot-0-8-micro-web-framework-tp4774449p4774693.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > >
