Re: Classpath or config?
Hello Chuck,
thanks for this good point. A link to the connectors page has been made
from part #2 of the tutorial.
Best regards,
Thierry Boileau
Given the number of times I've seen this question asked (both on this
list and here at my company), it seems to me that the configuring of
connectors should be directly addressed in the tutorial (since this is
where most people seem to start when trying to get something running).
--Chuck
-Original Message-
From: Thierry Boileau [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 10, 2007 10:59 AM
To: [EMAIL PROTECTED]
Subject: Re: Classpath or config?
Hello Donald,
this is a good remark. Your classpath need to be updated with some other
jars.
The Restlet framework is composed of 3 parts : restlet API, NRE
implementation of this API and some extensions.
Some of them are called "connectors" because they are responsible of
linking two components on the network.
You can find server connectors (for example, an HTTP connectors that get
requests from clients delegate the call to a restlet, component, etc and
give the response back) and client connectors that initiate requests to
a server.
Because you make some HTTP requests, you need to add one client HTTP
connector.
Please go to this page in order to make your choice between the two
provided by the current delivery and add the right jars :
http://www.restlet.org/documentation/1.0/connectors
Best regards,
Thierry Boileau
Hi,
I am just setting up Restlet at home. (Restlet-1.0rc6.zip) I am just
playing around at the moment and I have converted SimpleClient.java
into a Junit test.
I have com.noelios.restlet.jar and org.restlet.jar in my classpath but
get this warning.
(Using jre1.5.0_10).
10/04/2007 23:47:58 com.noelios.restlet.Engine createHelper
WARNING: No available client connector supports the required
protocols: HTTP . Please add the JAR of a matching connector to your
classpath.
Can someone tell me is this classpath or a config issue?
Regards
Donald.
public class SimpleClientTest extends TestCase {
public void testSimpleForm() throws Exception {
// Prepare the REST call.
Request request = new Request();
// Identify ourselves.
request.setReferrerRef("http://www.foo.com/";);
// Target resource.
request.setResourceRef("http://127.0.0.1:9876/test";);
// Action: Update
request.setMethod(Method.PUT);
Form form = new Form();
form.add("name", "John D. Mitchell");
form.add("email", "[EMAIL PROTECTED]");
form.add("email2", "[EMAIL PROTECTED]");
request.setEntity(form.getWebRepresentation());
System.out.println("client: one!");
// Prepare HTTP client connector.
Client client = new Client(Protocol.HTTP);
System.out.println("client: two!");
client.getLogger().log(Level.INFO, "client: two!");
// Make the call.
Response response = client.handle(request);
client.getLogger().log(Level.INFO, "client: three!");
if (response.getStatus().isSuccess()) {
client.getLogger().log(Level.INFO, "client: four!");
// Output the response entity on the JVM console
response.getEntity().write(System.out);
System.out.println("client: success!");
} else {
System.out.println(response.getStatus().getDescription());
fail("client: failure!");
}
}
}
RE: Defining Methods
Hi Sean, I don't think that there is a consensus on this point in the REST community. Some think that we should only rely on GET/POST as the other methods are not well supported by browsers. We Restlet, you can always rely on the tunnel service to dynamically change the method of request, by adding a "?method=DELETE" query. Also, WebDAV already defines extension methods like MOVE: http://www.webdav.org/specs/rfc2518.html#http.methods.for.distributed.author ing Some don't like the MOVE method because the origin server may not be in control of the target URI namespace. I like it if you restrict its usage to target URI that you control (or return an error). MOVE is clearly interesting because simply doing a GET/DELETE/PUT sequence isn't equivalent and as performant, especially when a resource has multiple representations. Now, for other methods like CANCEL, we would need to understand its meaning to be able to say whether it reduce the uniformity of the REST interface or whether is adds a useful method to it. Knowing that you can always tunnel those methods via a POST in Restlet should help in such a debate! Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis > Envoyé : jeudi 12 avril 2007 00:55 > À : [EMAIL PROTECTED] > Objet : Defining Methods > > Restlet has the ability to define our own Methods, say MOVE, > or CANCEL. > I'm in a debate that is essentially arguing the merits of defining an > application-specific Method, say CANCEL, vs. falling back on POST. > > I thought of 3 positions. > 1. Only use the 4 core Methods and if that isn't enough, define a new >URI. Problem is that this is equivalent to making the URI a verb. > 2. Always define application-specific Methods. Be totally > clear about what >the application is trying to do. > 3. Use the 4 methods whenever possible but add app-specific > Methods when it >makes sense. Problem I have with this is defining "When it > makes sense." > > Any and all opinions appreciated. > > Sean
RE: Question to all about visual webapps and Restlet
Hi John, [...] > I think it's helpful to think in terms of fundamental, "base" > resources and composite, "view" resources. An analogy is the > difference between "tables" and "views" in a relational database such > as Oracle. I agree, this is a useful analogy. > As you noted, in your example, it could be modelled where the same URL > is used but the two facets are distinguished by whether the caller > asks for the base (e.g., application/xml) or a human version (e.g., > xhtml). > > For other cases, I think it makes more sense to have the facets more > or less completely disjoint. The human useful, composite views may > make a lot more sense to the user if they have their own naming > hierarchy, etc. and just use the various, lower-level resources as > services, if you will, that are managed separately. I agree and would add that those lower-level resources (or core resources) could be modelled and exposed as either: - persistent POJOs (db4o, EJB3, etc.) - RESTful resources (via a separate Restlet application for example) In the second case, you could even think about a two-layer approach, where on Web Component would remotely access to an internal Core/Business Component. This way, your Core Component could be shared between several 'view' applications/components. Best regards, Jerome
RE: Reference not resolving
Hi John,
Thanks again for the useful feed-back. You made use rethink this issue more
deeply.
> > However, as said in chapter "5.1. Establishing a Base URI",
> of the Uri
> > reference (http://www.ietf.org/rfc/rfc3986.txt), a relative
> part cannot
> > be used in a context where the base reference is not
> defined. The fix
> > consists of throwing an IllegalArgumentException.
>
> That doesn't seem consistent with the other behavior of e.g.,
> returning null (or even an empty string).
The Reference class already throws a couple of exceptions when an attempted
operation is not valid. We return null when an optional data element is not
present (no query part for example) and we return "" when the data element
is present but empty.
Now, after a closer review, Thierry and I decided to change the
getRelativePart() method to act like this:
"Returns the relative part of relative references, without the query and
fragment. If the reference is absolute, then null is returned."
We also improved the Javadocs of the Reference class to specify clearly when
exception are raised and to detail the behavior of getRelativePart().
Changes committed to SVN.
> I am very concerned that these "disturbing" behaviors don't seem to be
> consistent which means they will be brittle to use because different
> assumptions will be made depending on a slew of things that may or may
> not be apparent.
The design of Reference has been carefully thought to fully support the URI
spec and provide a better alternative to JDK's URI class. The internal
behavior is simpler than what it looks, I will explain it below. I hope this
will reduce your uncomfort.
> Actually, no, that's not the behavior for web pages. To get
> "http://host.com/sub"; you would have to add "/sub" to e.g.,
> "http://host.com/dir";. Adding "sub" to e.g. "http://host.com/dir";
> should result in "http://host.com/dir/sub";.
As there is no trailing slash after "dir", the current output is correct.
See the URI spec for more complex examples:
http://gbiv.com/protocols/uri/rfc/rfc3986.html#reference-examples
Note that we enforce all the URI spec examples with a set of unit tests.
Looking at how tricky those examples are, we feel very confident about the
quality of Reference's output :)
> [...]
> > host = new Reference("http://host.com";)
> > Schemehttp
> > Authority host.com
> > Path null
> > RemainingPart http://host.com
> > toString http://host.com
> > TargetRef http://host.com
> > RelativePart IllegalArgumentException
>
> Sticking to the convention of using null for missing elements, I'd say
> that the RelativePart should be null. It's just missing (or "not
> applicable", if you will) -- just like the Path.
Agreed. We now return null in this case.
> > slashdir = new Reference(host, "/dir")
> > Schemenull
> > Authority null
> > Path /dir
> > RemainingPart null
> > toString /dir
> > TargetRef http://host.com/dir
> > RelativePart /dir
>
> If this is built relative to the 'host' reference, why isn't slashdir
> "inheriting" the information from the 'host'?
Because the base reference is only a property of the Reference ("baseRef").
When you use the "Reference(base, path)" constructor, it is equivalent to
doing:
ref = new Reference(path);
ref.setBaseRef(base);
The base ref is not automatically resolved or "merged" with the rest of the
reference information (the path here). For example, this let's you reuse a
single reference as the base of several relative references. If you modify
the base reference, all relative references are still accurate.
Frequently you will want to resolve the reference to "merge" the base
reference with the current reference info (for example a relative path). For
this purpose you can use the getTargetRef() which will return a new resolved
Reference instance, an absolute URI reference with no base reference.
> I.e., the abstract model of what Reference has been created for needs
> to be clear and clearly explained. Is it a DAG or a tree or a wacky
> string or what? How does each Reference stand on it's own? How do all
> of the pieces compose and why? What about other facets of a reference
> such as anchors (e.g. "#footer1") and parameters get folded in? Etc.
> Basically, how can users understand how it should work without going
> insane?
The Reference stores its data as a single string, the one passed to the
constructor. This string can always be obtained using the toString() method.
We also maintain a couple of integer indexes to improve the extraction time
of various reference properties (URI components).
When you modify a specific component of the URI reference, via the setPath()
method for example, we simply regenerate the internal string by updating
only the relevant part. We try as much as possible to protect the bytes
given to the Reference class instead of transparently parsing and
normalizing the URI data. Our idea is
RE: Question to all about visual webapps and Restlet
Hi Vincent, > So you're forcing one resource to be aware of other resources > just because of > the way your user interface in designed. If you switch to > HTML frames, you no > longer need these dependencies because each frame displays > only one resource > (the content frame, the profile frame, the navigation frame, etc.). Yes, in this case the resource is a "view resource". The addition of frames wouldn't break the design, the Web representation would just remove the contextual information (sidebar, etc.) and we would add new dedicated resources for the other frames. > And what about cross references? If you click on a post in > one of the thread, > the 'post' resource must know about the 'profile' resource > because it's > part of its 'contextual information'. Now let's say you have > a 'More' link in > the profile section to display more of your profile info. In > order to redisplay > the page, the 'profile' resource will have to know about the > 'post' resource > too (because when you GET /profile/123;details, you need to > include the > current post). Imagine the graph (and the resulting > maintenance nightmare) if > you have 5 resources displayed on one page. I'm not sure to follow you precisely, but for sure a Web page is a representation of a single target resource. It doesn't matter how many sub-resources or domain objects were used to build this representation. > And what if the same resource can be displayed in several > type of views? Take > this forum, for instance: > When you a click on a thread, the post is displayed in the > bottom part of the > screen. You can also click on the direct-link and have the > post displayed on a > new page (without the threads). gmane uses frames to achieve > this, but how would > you do it without frames? Include the view in the url? > > GET > http://article.gmane.org/gmane.comp.java.restlet/1871;view=threaded > GET http://article.gmane.org/gmane.comp.java.restlet/1871;view=single > > Or you could decide that what you're viewing is the form, and > the uri becomes: > GET http://article.gmane.org/gmane.comp.java.restlet?activeView=1871 > > The danger with this approach is that it forces you to think > in terms of pages > (the forum, the main page, etc.) instead of resources. Or > more exactly: > your pages become your resources. Exactly, and their is nothing fundamentaly wrong with this. What is important is that you don't create unnecessary "page" resources. As soon as you add a "?page=2" query parameter, you identify a resource that is separate from the one identified by "?page=3". There is nothing you can do against this. What is essential is that your core domain model is well defined and reused by all your view resources. This core domain model can also be distributed and implemented as RESTful resource if you can afford this flexibility. > I've been thinking a lot about this too, and I came to the > conclusion that > the best way to put a face on a restfull app is the have the > client -not > the server- assemble the view. > The simplest (an ugliest) way is to use frames; a better solution is > to make Ajax calls to the server to retrieve individual > resources, and > insert the returned html (or xml, json, etc) in the page. > It also scales better if the application is stateless (no > need to retrieve the > profile each time we display a post). > Of course, this is valid only for relatively complex > application(e.g. a webmail > client). But if your application is restul and your UI > moderately complex, it > calls for a single-page UI (a la GWT) as opposed as the > standard multi-page > design. My concern with those approaches (AJAX) is that they somewhat break the hyperlink design of the Web, and the ability to bookmark each state of your application. Best regards, Jerome
a gzip representation
I was looking for some guidance on how i would package a gzipped java serialized object. Do I need to extend ObjectRepresentation class and use content type application/gzip or is there some way I can use the ObjectRepresentation class with some form of encoding. cheers
RE: a gzip representation
Hi Jim, You can have a look at the com.noelios.restlet.application.EncodeRepresentation class. We are also planning on adding an automatic/configurable encoding service: http://restlet.tigris.org/issues/show_bug.cgi?id=208 Best regards, Jerome > -Message d'origine- > De : Jim Alateras [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 12 avril 2007 15:19 > À : [EMAIL PROTECTED] > Objet : a gzip representation > > I was looking for some guidance on how i would package a gzipped java > serialized object. Do I need to extend ObjectRepresentation class and > use content type application/gzip or is there some way I can use the > ObjectRepresentation class with some form of encoding. > > cheers >
Re: a gzip representation
Jerome Louvel wrote: Hi Jim, You can have a look at the com.noelios.restlet.application.EncodeRepresentation class. So i can use it to wrap an ObjectRepresentation. Will the Encoding i pass across to it override the HTTP content-type header (i.e. if the encoding is set to gzip then the content-type hesader will be application/gzip. cheers
Re: a gzip representation
Hi Jim,
I want to precise that the EncodeRepresentation automatically sets the
"content-encoding" header and keep intact the "content-type" of the
wrapped representation.
It allows Firefox to decodes on the fly the gzip stream and restore the
wrapped representation.
If you want to use EncodeRepresentation because it provides the gzip
compression service, just take car of setting the right content-type and
content-encoding for your representation:
Representation representation = new
EncodeRepresentation(Encoding.GZIP, new StringRepresentation("Hello
World!", MediaType.TEXT_PLAIN));
representation.setMediaType(MediaType.APPLICATION_GNU_ZIP);
representation.getEncodings().clear();
I hope this will help you.
Best regards,
Thierry Boileau
Hi Jim,
You can have a look at the
com.noelios.restlet.application.EncodeRepresentation class.
So i can use it to wrap an ObjectRepresentation. Will the Encoding i
pass across to it override the HTTP content-type header (i.e. if the
encoding is set to gzip then the content-type hesader will be
application/gzip.
cheers
Re: Defining Methods
Hi Jerome,
Jerome Louvel noelios.com> writes:
>
> Hi Sean,
>
> I don't think that there is a consensus on this point in the REST community.
>
> Some think that we should only rely on GET/POST as the other methods are not
> well supported by browsers. We Restlet, you can always rely on the tunnel
> service to dynamically change the method of request, by adding a
> "?method=DELETE" query.
I should have mentioned that this is a web service so browsers don't need to
be involved. Does that change anything?
> Also, WebDAV already defines extension methods like MOVE:
> http://www.webdav.org/specs/rfc2518.html#http.methods.for.distributed.author
> ing
>
> Some don't like the MOVE method because the origin server may not be in
> control of the target URI namespace. I like it if you restrict its usage to
> target URI that you control (or return an error).
>
> MOVE is clearly interesting because simply doing a GET/DELETE/PUT sequence
> isn't equivalent and as performant, especially when a resource has multiple
> representations.
>
> Now, for other methods like CANCEL, we would need to understand its meaning
> to be able to say whether it reduce the uniformity of the REST interface or
> whether is adds a useful method to it.
The result of a CANCEL is that an invoice is canceled in the DB but still
available. I don't think it is a useful new method in the sense that MOVE
is. I see 'cancel' as a resource state change that should be a POST
(although we don't need to post any data). A
DELETE doesn't seem right since we aren't deleting the invoice, just marking
it as canceled.
Others don't see it that way. I don't see CANCEL adding any new behavior so
it's hard for me to justify.
More detail. We have three operations on an invoice (that is created
elsewhere).
1. Get invoice (GET)
2. Compute canceled invoice and return the savings
3. Cancel invoice
>From a purely URI perspective, all I need is:
router.attach("/orders/invoices/{invoiceId}", InvoiceResource.class);
But the limited number of methods gets in my way. I think 1 & 2 should be a
GET and 3 should be a POST.
I could define a new URI, say,
router.attach("/orders/invoices/{invoiceId}/cancel", InvoiceResource.class);
but that seems unfortunate.
Any suggestions?
Thanks,
Sean
> Knowing that you can always tunnel those methods via a POST in Restlet
> should help in such a debate!
>
> Best regards,
> Jerome
>
> > -Message d'origine-
> > De : news [mailto:news sea.gmane.org] De la part de Sean Landis
> > Envoyé : jeudi 12 avril 2007 00:55
> > À : discuss restlet.tigris.org
> > Objet : Defining Methods
> >
> > Restlet has the ability to define our own Methods, say MOVE,
> > or CANCEL.
> > I'm in a debate that is essentially arguing the merits of defining an
> > application-specific Method, say CANCEL, vs. falling back on POST.
> >
> > I thought of 3 positions.
> > 1. Only use the 4 core Methods and if that isn't enough, define a new
> >URI. Problem is that this is equivalent to making the URI a verb.
> > 2. Always define application-specific Methods. Be totally
> > clear about what
> >the application is trying to do.
> > 3. Use the 4 methods whenever possible but add app-specific
> > Methods when it
> >makes sense. Problem I have with this is defining "When it
> > makes sense."
> >
> > Any and all opinions appreciated.
> >
> > Sean
>
>
RE: Defining Methods
Hi Sean,
> I should have mentioned that this is a web service so
> browsers don't need to
> be involved. Does that change anything?
No, if the HTTP client is somewhat limited regarding methods, the tunnel
service can still be used.
> The result of a CANCEL is that an invoice is canceled in the
> DB but still
> available. I don't think it is a useful new method in the
> sense that MOVE
> is. I see 'cancel' as a resource state change that should be a POST
> (although we don't need to post any data). A
> DELETE doesn't seem right since we aren't deleting the
> invoice, just marking
> it as canceled.
> Others don't see it that way. I don't see CANCEL adding any
> new behavior so
> it's hard for me to justify.
CANCEL seems a bit too domain specific to become part of a uniform
interface. Would it be usable for resources other than invoices? The way I
would solve this would be to add a child resource InvoiceStatus for every
Invoice created. You could then simply GET/PUT this status (CREATED | ... |
CANCELLED).
> More detail. We have three operations on an invoice (that is created
> elsewhere).
> 1. Get invoice (GET)
> 2. Compute canceled invoice and return the savings
> 3. Cancel invoice
>
> From a purely URI perspective, all I need is:
>
> router.attach("/orders/invoices/{invoiceId}", InvoiceResource.class);
>
> But the limited number of methods gets in my way. I think 1 &
> 2 should be a
> GET and 3 should be a POST.
>
> I could define a new URI, say,
> router.attach("/orders/invoices/{invoiceId}/cancel",
> InvoiceResource.class);
> but that seems unfortunate.
>
> Any suggestions?
I hope the above solution works for you.
Best regards,
Jerome
Re: Question to all about visual webapps and Restlet
Hi Jerome, > > > So you're forcing one resource to be aware of other resources > > just because of > > the way your user interface in designed. If you switch to > > HTML frames, you no > > longer need these dependencies because each frame displays > > only one resource > > (the content frame, the profile frame, the navigation frame, etc.). > > Yes, in this case the resource is a "view resource". The addition of frames > wouldn't break the design, the Web representation would just remove the > contextual information (sidebar, etc.) and we would add new dedicated > resources for the other frames. > > > And what about cross references? If you click on a post in > > one of the thread, > > the 'post' resource must know about the 'profile' resource > > because it's > > part of its 'contextual information'. Now let's say you have > > a 'More' link in > > the profile section to display more of your profile info. In > > order to redisplay > > the page, the 'profile' resource will have to know about the > > 'post' resource > > too (because when you GET /profile/123;details, you need to > > include the > > current post). Imagine the graph (and the resulting > > maintenance nightmare) if > > you have 5 resources displayed on one page. > > I'm not sure to follow you precisely, but for sure a Web page is a > representation of a single target resource. It doesn't matter how many > sub-resources or domain objects were used to build this representation. > Sorry if I wasn't clear. Let me try again. You display 2 resources on one page: 1) your profile. By default, the Profile section display your name, but it include a More link that let's you display your name, your email, the number of posts you've made, etc. 2) the forum When you click on a forum thread, the Forum resource must pull the Profile resource out of the DB in order to redisplay the page. When you click on the More link (in the Profile section), the Profile resource must pull out the Forum info out of the DB to be able to retrieve the page. So, you're introducing a dependency between these two resources. If you later decide to display the weather report on that page, both the Profile and Forum resources will have to be made aware of the WeatherReport resource in order to display the page. And so on. If you say that the Profile and WeatherReport resources are part of the representation of the Forum resource, you must also admit that the Forum is part of the Profile's (or WeatherReport's) representation. I think this creates an unmanageable graph. -vincent.
Re: Question to all about visual webapps and Restlet
> I agree and would add that those lower-level resources (or core resources) > could be modelled and exposed as either: > - persistent POJOs (db4o, EJB3, etc.) > - RESTful resources (via a separate Restlet application for example) > > In the second case, you could even think about a two-layer approach, where > on Web Component would remotely access to an internal Core/Business > Component. This way, your Core Component could be shared between several > 'view' applications/components. So, say we have a page that displays a picture of an apple and a picture of an orange. When we click on either picture, we want to replace it by the text representation of the selected fruit (we we want to keep displaying the picture of the other fruit). We have 3 resources: MainPage, Apple, Orange. Apple and Orange are what you call 'low-level' resources'; the Mainpage resource is the highest abstraction. To display the main page you GET /mainPage What are the apppe's and orange's URI's like? For the apple: /mainPage?orange=picture&apple=text For the orange: /mainPage?orange=text&apple=picture Is that what you had in mind? What if we want to modify the orange? Do we PUT the mainPage, passing it the Orange info? -vincent.
Re: Reference not resolving
The change to getRemainingPart() catches all Exceptions and silently returns null. While the set of possible exceptions is small (StringIndexOutOfBounds and NullPointerException), this class may be extended or modified to include a wider set of failure cases. I request validation be performed for the expected cases and let unexpected exceptions propagate.
Request for change to Representation
Gentlemen, Currently, a Reference instance may be in any state from empty, to invalid, to relative, to absolute. In any of those states it may or may not have a baseRef. No exceptions appear until certain getter methods are called. I agree that we should be able to modify the parts of a Reference, but I will argue the flexibility of having a Reference which cannot be resolved to an absolute reference (e.g., relative internalRef with null baseRef) introduces problems which are difficult to validate after the fact. I humbly request that the Reference class attempts to be "fully-resolvable". This would require at least the following changes: - remove default constructor - validate that uriReference is absolute in constructor Reference(String uriReference) - validate that uriReference is relative in all Reference(Reference baseRef, ...) constructors - isRelative() based on presence of baseRef - set* methods on relative Reference throw IllegalArgumentException if applicable (callers can use isRelative() to check beforehand) These changes would allow some measure of consistency, keep the flexibility of modifiable references, and simplify working with deep Reference chains. I imagine it would also simplify some of the code. Your thoughts? And, yes, since I'm making the proposal, I would be willing to do the work.
Re: Basic Auth & Post -- Works the second time but not the first
On 4/11/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: Hi Alex, Your code looks fine. This may be due to a behavior from Firefox in order to prevent multiple executions of the non-idempotent POST method. I think this would work as you expect with a GET. Maybe you should consider pre-authenticating before submitting via POST? Yes, that is in fact the case. After more testing, unless you specify the authentication information, the POST will not automatically "repost"--which makes sense. Fortunately, I built in the ability to enter username/password information in my Poster extension for firefox and all is well. Thanks! --Alex Milowski
RE: Reference not resolving
Justin, I have refactored the implementation to not rely on this try/catch block anymore. Thanks for the suggestion. Thanks for testing this from SVN if you can. Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Justin C. > van Vorst > Envoyé : jeudi 12 avril 2007 21:09 > À : [EMAIL PROTECTED] > Objet : Re: Reference not resolving > > The change to getRemainingPart() catches all Exceptions and > silently returns > null. While the set of possible exceptions is small > (StringIndexOutOfBounds and > NullPointerException), this class may be extended or modified > to include a wider > set of failure cases. I request validation be performed for > the expected cases > and let unexpected exceptions propagate. >
Re: a gzip representation
Thierry,
Thanks for the information. It helps enormously
cheers
Thierry Boileau wrote:
Hi Jim,
I want to precise that the EncodeRepresentation automatically sets the
"content-encoding" header and keep intact the "content-type" of the
wrapped representation.
It allows Firefox to decodes on the fly the gzip stream and restore the
wrapped representation.
If you want to use EncodeRepresentation because it provides the gzip
compression service, just take car of setting the right content-type and
content-encoding for your representation:
Representation representation = new
EncodeRepresentation(Encoding.GZIP, new StringRepresentation("Hello
World!", MediaType.TEXT_PLAIN));
representation.setMediaType(MediaType.APPLICATION_GNU_ZIP);
representation.getEncodings().clear();
I hope this will help you.
Best regards,
Thierry Boileau
Hi Jim,
You can have a look at the
com.noelios.restlet.application.EncodeRepresentation class.
So i can use it to wrap an ObjectRepresentation. Will the Encoding i
pass across to it override the HTTP content-type header (i.e. if the
encoding is set to gzip then the content-type hesader will be
application/gzip.
cheers
Re: HTTP Headers
Jerome Louvel noelios.com> writes: > Hi Dig, > > Complete caching support is not available in the API yet. It is planned for > a future release, see: http://restlet.tigris.org/issues/show_bug.cgi?id=25 > > You are touching a sensitive point. I have relaxed the usage of the standard > HTTP headers that are not yet supported in the API. You will still get a > message in the logs (INFO level instead of WARNING), but it will work. > Checked in SVN. > > Also, I have entered a new issue to keep track of all unsupported standard > HTTP headers: > http://restlet.tigris.org/issues/show_bug.cgi?id=282 > > Best regards, > Jerome Hi Jerome, Thanks for the response - very helpful. I'll implement these headers once I upgrade. Best regards, Dig.
