How do I define a root URL for my Restlet application
Hi all,
I've been going through the First Resource tutorial for Restlet 1.1, and would
like to find out how to define a root URL for the various routes (to
resources) defined in my Restlet application. I am deploying the Restlet
application as a stand-alone Java application and not in a Servlet container.
To explain further:
If I have the createRoot() method defined in my Application subclass as follows:
public Restlet createRoot() {
Router router = new Router(getContext());
router.attach(/items, ItemsResource.class);
router.attach(/items/{itemName}, ItemResource.class);
return router;
}
How do I define a root URL so that all resource routes are interpreted relative
to that URL?
For example if I want the root URL to be /myapp, then I want to retrieve the
resources above as follows:
http://localhost:8082/myapp/items
http://localhost:8082/myapp/items/1234
I realise I can just prepend /myapp/ to the resource paths in the
router.attach() calls above, but if I have lots of path to resource mappings
then editing the whole lot if I want to change the root URL would be quite
tedious.
I've trawled through the tutorials and the JavaDocs so maybe I'm missing
something really obvious.
Thanks in advance
Glen
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592602
Redirecting via client dispatcher
Hi!,
Can anyone help me explain this redirector behavior. I was testing a load
balancing restlet web service basically it just redirect a request to the
destination.
Example http://localhost:8183/webservice/resource1/test this will be
redirected to any of the specified route destination in a round robin, example
destination http://localhost:50011/test as expected.
With our test case scenario of actual production issues that might occur,
we stop on retlet web service of the destination let say
http://localhost:50012. and we do the following
First Request: http://localhost:8183/webservice/resource1/test --
redirected to http://localhost:50011/test --it is successful
Second Request: http://localhost:8183/webservice/resource1/test --
redirecting to http://localhost:50012/test -- but it is not showing or it like
requesting indefinitely, no output is receive, until I stop the browser.
INFO: Redirecting via client dispatcher to: http://localhost:50012/test1;
-- last log
Question does the VirtualHost have any means of detecting that the
destination is not online, if can't determine it? how to solve this issue?
///
public static void main(String[] args) throws Exception{
Component component=new Component();
component.getServers().add( Protocol.HTTP, 8182 ); // Private
component.getServers().add( Protocol.HTTP, 8183); // Public
//Add a new HTTP client
component.getClients().add( Protocol.HTTP );
/**
* Create virtual Host for Private use for administrative purposes
*/
VirtualHost privateHost = new VirtualHost(component.getContext());
privateHost.setHostDomain(localhost);
privateHost.setHostPort(8182);
VirtualHost proxyHost = new VirtualHost(component.getContext());
proxyHost.setHostDomain(localhost);
proxyHost.setHostPort(8183);
proxyHost.setRoutingMode(Router.MODE_NEXT_MATCH);
/**
* Load balancing path
*/
proxyHost.attach(/webservice/resource1,new
Redirector(component.getContext(), http://localhost:50011{rr};,
Redirector.MODE_SERVER_OUTBOUND));
proxyHost.attach(/webservice/resource1,new
Redirector(component.getContext(), http://localhost:50012{rr};,
Redirector.MODE_SERVER_OUTBOUND));
component.getHosts().add(privateHost);
component.getHosts().add(proxyHost);
component.start();
}
///
I appreciate your feedback and Thanks
Sincerely,
Gerald G. Ternola
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592601
RE: How do I define a root URL for my Restlet application
Hello,
when you attach your application at your component, you can specify a root URL:
component.getDefaultHost().attach(/firstResource, new
FirstResourceApplication());
Inside your application, if you want to define a root URL for a set of
branches: just attach a router:
Router root = new Router(getContext());
Router branch1 = new Router(getContext());
branch1.attach(/items, ItemsResource.class);
branch1.attach(/items/{itemName}, ItemResource.class);
root.attach(/branch1, branch1);
return root;
Best regards,
Thierry Boileau
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592633
Subscribe
-- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591900
RE: Redirecting via client dispatcher
Hello Gerald,
-- but it is not showing or it like requesting indefinitely, no output is
receive, until I stop the browser.
Could you tell us what client (internal, net or httpclient, etc) and server
connectors (internal, jetty, simple, grizzly, netty, etc) are you using on both
servers (proxy and origin servers) ?
What release of restlet are you using?
Just one feedback, could you instantiate your Redirector as follow?
new Redirector(null, http://localhost:500 11{rr});
The default mode is actually server_outbound, and the component's context is
not intended to be passed to a child constructor.
Best regards,
Thierry Boileau
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592683
Re: What to do about sessions?
It's hard for me to see Comet as RESTful. I would consider it a new use of HTTP that demands a new way of thinking. You'd probably want to use a lower level API than Restlet, so you can fully leverage asynchronicity. Have you considered repeat rapid polling instead of using Comet? On 04/21/2010 05:12 PM, Marc Larue wrote: Ok, I realize you are all talking mostly from a B2B perspective. I'm developing a realtime comet system for multiplayer games (Ajax, JSON, Rupy); so my perspective is a little different. Right now I'm trying to figure out how to make my XSS messaging system as cheaply scalable as possible; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Laruem...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591952 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592758
HTTPS and HTTP?
Hi, i'd like to know if there's a way to have on the same application running HTTPS resources and HTTP. My idea is to have a login resource via HTTPS where a session is returned if user/password are ok and then check the session in other HTTP resources (so the overload of HTTPS is saved) Thanks! -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/HTTPS-and-HTTP-tp4946235p4946235.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592789
Re: HTTPS and HTTP?
A common solution I use is to have my loadbalancer (I like PerlBal) handles HTTPS divert HTTP and HTTPS to different ports, for example 80 for HTTP and 81 for HTTPS. You can run your Restlet component with two servers to answer both of these, and then test for which port requests are coming through to make decisions based on HTTP vs. HTTPS. -Tal On 04/22/2010 01:09 PM, gonzajg wrote: Hi, i'd like to know if there's a way to have on the same application running HTTPS resources and HTTP. My idea is to have a login resource via HTTPS where a session is returned if user/password are ok and then check the session in other HTTP resources (so the overload of HTTPS is saved) Thanks! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592791
Re: Protobuf, protocolbuffer
A while back I wrote a Restlet Representation that could be used for wrapping a protobuf. The code is in the issue tracker, but i never got around to cleaning it up such that it could be checked in. Unfortunately my current job makes contributing to Restlet (or any open source project) a bit painful, so I probably won't be able to finish the work. Dave On Wed, Apr 21, 2010 at 3:26 AM, Alexander J. Perez Tchernov xas...@gmail.com wrote: I suppose it can be great if to choose protobuf+gzip/protobuf+deflate (*) media-type. Some links as well ... *Protobuf* http://code.google.com/p/protobuf-gwt/ http://code.google.com/p/protobuf-js/ http://code.google.com/p/google-web-toolkit/issues/detail?id=2649 * Rest* http://code.google.com/p/gwt-rest/ http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet.html *Benchmarking* http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking (*) http://www.qos.ch/pipermail/logback-dev/2009-March/003889.html On Wed, Apr 21, 2010 at 12:58 PM, Xavier M. xavier.meh...@gmail.comwrote: Hello, I would like to know if it is intended to use protobuf/protocolbuffer for exchanging compressed structured data over the net through Rest. http://code.google.com/p/protobuf/ http://code.google.com/intl/fr/apis/protocolbuffers/docs/overview.html regards Xavier -- Best regards, ~ Xasima ~ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592800
Re: What to do about sessions?
Well, I wrote my own NIO application server, so yes on both accounts! Polling is not an option, I need to support thousands of concurrent clients per hardware. http://rupy.googlecode.com /m On Thu, 22 Apr 2010, Tal Liron wrote: It's hard for me to see Comet as RESTful. I would consider it a new use of HTTP that demands a new way of thinking. You'd probably want to use a lower level API than Restlet, so you can fully leverage asynchronicity. Have you considered repeat rapid polling instead of using Comet? On 04/21/2010 05:12 PM, Marc Larue wrote: Ok, I realize you are all talking mostly from a B2B perspective. I'm developing a realtime comet system for multiplayer games (Ajax, JSON, Rupy); so my perspective is a little different. Right now I'm trying to figure out how to make my XSS messaging system as cheaply scalable as possible; specifically how to transfer users from the lobby to a game room on another server and how to build a generic protocol for this. Comet is hard to build without session state since you communicate on two sockets with every client and in my case the session is used to tie these together. Anyhow I have a stateful client, now I just need to figure out the best way to synchronize clients and I think you are right; CPU goes before bandwidth in my case too. Maybe a fullstate monopacket protocol? Cheers, /marc On Wed, 21 Apr 2010, Tal Liron wrote: REST services are only as chatty as however you define your resources. I've seen many REST architectures suffering from a failure of imagination: the architects assume that resource has to have a one-to-one mapping with database row or other concrete entity, when in fact there is not such requirement. Resources should be use-specific, logical to the application, not to its underlying implenetation. It's possible to devise resources that are logical associations of various complex business logic, and do as much as you do with a SOAP request. Also, I don't think REST has to be stateless. HTTP headers are used specifically for passing state, and cookies are full-blown shared state. Why not implement sessions via cookies? Of course, there are potential scalability issues with shared state and sessions, but these are general problems and not specifically addressed by REST. My advice: 1) Use cookies, they are good, but -- 2) Don't maintain heavy, persistent sessions on the server. Create a lightweight scheme that lets you quickly do a secure operation per user. 3) Think very careful about what you consider a resource, and try to bunch as much functionality as you can into one request. This will also help you in minimizing the costs of session access. -Tal On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt stephen.grouc...@gmail.com wrote: REST services are definitely chatty, especially when compared to SOAP webservices that might perform N operations in one shot. To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a client picks its way through multiple server resources via links that are present in the representations, to perform some task. Being bad on bandwidth seems to me to be an inherent part of the architectural style of REST. So, I think this just means that bandwidth has to be a consideration when you are deciding what architectural style fits your system's domain. On Wed, Apr 21, 2010 at 12:58 PM, Marc Laruem...@rupy.se wrote: I'm just chiming in to this, so this means with REST you have to send the whole state back and fourth between client and server on every request/response. So what does REST say about bandwidth, it's not a problem? Cheers, /marc On Wed, 21 Apr 2010, Thierry Boileau wrote: Hi Matt, from what I see, the authenticator just have to check the presence of the user principals (set by GAE) in the authenticate(Request, Response): !request.getClientInfo().getPrincipals().get(0). You can provide a verifier in order to check that the application knows the user identified by the principal name (actually the user's mail) and set the clientInfo#user. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591291 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591738 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591936 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2591952 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592758
Re: HTTPS and HTTP?
Thanks Tal! I solved it your way i think. But without load balancer. I added HTTP server on port 80 and HTTPS on port 81 and the login resource checks the protocol like this: if(request.getProtocol() != Protocol.HTTPS) Hope that's right and make my app secure. Thank you again! -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/HTTPS-and-HTTP-tp4946235p4946625.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2592840
