How flush output stream
Hi, in the Representation represent(Variant variant) method i would like to flush all bytes back to the browser before this method returns (so I know that all went well and commit the task). Is there any access to HttpServletResponse.getOutputStream.flush() or similar? Thanks Marcel -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/How-flush-output-stream-tp5756814p5756814.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2683558
Re: Adding "sessions" to a REST(let) application
There's nothing in REST for or against sessions -- that's not its domain. Your higher level app can definitely have sessions. I do not recommend renewing your cookie for every request to keep the session from expiring. Instead, have your cookie store a session ID, and maintain a session table on your server (via a memory DB or persistent, as you prefer). You can update the session expiration per hit you get on resources within the session. This is standard practice for web applications: even if they are not overtly RESTful, then need to use HTTP. :) Where this can affect REST is your URI space: sessions end up being resources. For example, you might allow a superuser access to a resource which lets them list all open sessions, and then perhaps query session data (GET) and logging out sessions (DELETE). It's quite rare for me to write a RESTful service that does not have some kind of sessions. -Tal On 11/19/2010 10:53 AM, Fabian Mandelbaum wrote: > Hello there, > > We're currently facing a dillema with our REST application. Since we > sell accounts for this application, we'd need a way to limit the > concurrent number of users using an account. It happens that we sell > one account and have many users use the authentication credentials of > that account. > > Now, REST principles state that the server must not store any > application state (for example, user sessions), so this seems to > contradict our (commercially-motivated, agreed) needs. > > We thought about having the client send a cookie (I'm cookie-ignorant) > with each request, and have the resources check that cookie, which > would 'expire' after a given ammount of time, or when the user > explicitly states so (there's a Logout button on our UI, which just > works on IE and FF for now, using a REST-based "logout" technique: > basically it sends bogus authentication credentials invalidating the > browser's cached ones). Cookies seem to be accepted as a RESTful way > of exchanging such "state" information. > > This of course, posses another issue, how does the user renew the > cookie when the session is nearing expiration? Is this handled > automatically? As I've mentionned above, I'm cookie-ignorant, forgive > me if I ask nonsense. > > How did you solve this issue on your REST(let) applications? Any > examples I can take a look at? > > Thanks in advance for your answers. > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2683498
Re: Adding "sessions" to a REST(let) application
Hi Fabian, It could be renewed with every request send to the server. This is the >> same as with sessions. > So, the cookie has to be "refreshed" (so to speak) on each request? If you want to save a new cookie, than yes. Because you have to renew the expiration timestamp you have to send a new timestamp. > Should I also store cookie-user state somewhere? I think to count the users you have to do this, but I'm not sure. Then you have to implement sessions, than you could also use Servlet sessions You should put this in a filter (independently if for servlet or for Restlet), so that your application stays free of it. > So, the architecture would be like this: > > Client --- Request --> Servlet API authentication "frontend" --- > Request ---> REST Statleless core Yes. > I'd have to sort of change my Guard for something using the Servlet > API? Can I integrate that into my existing Guard (I already have > guarded resources)? There I can't tel you much. I think there is something in Restlet to read authentication data from e.g. Servlet API, but I'm not sure. Take a look to the server connector main class. best regards Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2683349
Re: Adding "sessions" to a REST(let) application
Hello Stephan, thanks for your answers, more questions between lines: On Fri, Nov 19, 2010 at 2:13 PM, Stephan Koops wrote: > Hi Fabian, >> We thought about having the client send a cookie (I'm cookie-ignorant) >> with each request, and have the resources check that cookie, which >> would 'expire' after a given ammount of time, or when the user >> explicitly states so (there's a Logout button on our UI, which just >> works on IE and FF for now, using a REST-based "logout" technique: >> basically it sends bogus authentication credentials invalidating the >> browser's cached ones). Cookies seem to be accepted as a RESTful way >> of exchanging such "state" information. >> >> This of course, posses another issue, how does the user renew the >> cookie when the session is nearing expiration? Is this handled >> automatically? As I've mentionned above, I'm cookie-ignorant, forgive >> me if I ask nonsense. > It could be renewed with every request send to the server. This is the > same as with sessions. So, the cookie has to be "refreshed" (so to speak) on each request? Should I also store cookie-user state somewhere? >> Now, REST principles state that the server must not store any >> application state (for example, user sessions), so this seems to >> contradict our (commercially-motivated, agreed) needs. > You could handle this via Servlet API. Than your Restlet application > stays stateless, and you have your session to chek. > So, the architecture would be like this: Client --- Request --> Servlet API authentication "frontend" --- Request ---> REST Statleless core I'd have to sort of change my Guard for something using the Servlet API? Can I integrate that into my existing Guard (I already have guarded resources)? > best regards > Stephan > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2683255 > -- Fabián Mandelbaum IS Engineer -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2683338
Re: Adding "sessions" to a REST(let) application
Hi Fabian, > We thought about having the client send a cookie (I'm cookie-ignorant) > with each request, and have the resources check that cookie, which > would 'expire' after a given ammount of time, or when the user > explicitly states so (there's a Logout button on our UI, which just > works on IE and FF for now, using a REST-based "logout" technique: > basically it sends bogus authentication credentials invalidating the > browser's cached ones). Cookies seem to be accepted as a RESTful way > of exchanging such "state" information. > > This of course, posses another issue, how does the user renew the > cookie when the session is nearing expiration? Is this handled > automatically? As I've mentionned above, I'm cookie-ignorant, forgive > me if I ask nonsense. It could be renewed with every request send to the server. This is the same as with sessions. > Now, REST principles state that the server must not store any > application state (for example, user sessions), so this seems to > contradict our (commercially-motivated, agreed) needs. You could handle this via Servlet API. Than your Restlet application stays stateless, and you have your session to chek. best regards Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2683255
Adding "sessions" to a REST(let) application
Hello there, We're currently facing a dillema with our REST application. Since we sell accounts for this application, we'd need a way to limit the concurrent number of users using an account. It happens that we sell one account and have many users use the authentication credentials of that account. Now, REST principles state that the server must not store any application state (for example, user sessions), so this seems to contradict our (commercially-motivated, agreed) needs. We thought about having the client send a cookie (I'm cookie-ignorant) with each request, and have the resources check that cookie, which would 'expire' after a given ammount of time, or when the user explicitly states so (there's a Logout button on our UI, which just works on IE and FF for now, using a REST-based "logout" technique: basically it sends bogus authentication credentials invalidating the browser's cached ones). Cookies seem to be accepted as a RESTful way of exchanging such "state" information. This of course, posses another issue, how does the user renew the cookie when the session is nearing expiration? Is this handled automatically? As I've mentionned above, I'm cookie-ignorant, forgive me if I ask nonsense. How did you solve this issue on your REST(let) applications? Any examples I can take a look at? Thanks in advance for your answers. -- Fabián Mandelbaum IS Engineer -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2683227
RE: Restlet and SIP
I am a seasoned developer with experience in GWT but admittedly I am a VOIP neophyte. I need a SIP client that is browser based. Simple as that. I can't afford client software installs on this one. I am using GWT for other parts of the app and would like to keep it all under one hood so to speak. Your point about GWT and HTTP is well taken. Clearly, my ignorance has shown. I was reviewing a project called GWT-Voice to see if I could possibly use it for the RTP part of the problem. Then I stumbled across the Restlet road map and got a little excited. So if you don't mind schooling me a bit, browser based VOIP am I out of luck all together? or just with the GWT business? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2682876
RE: Can not access wiki..
Hello Nick, another person has reported this error in the Opera forum => http://my.opera.com/community/forums/topic.dml?id=807312&t=1290154364&page=1#comment7706822 Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2683026
