Wednesday, October 11, 2017

JAX-RS tutorials and documentation

Here a reasoned discussion about CacheControl and ETag

Here all the HTTP 1.1 headers specifications

deploy it in a PVRestRS project and hit it with http://localhost:8080/PVRestRS/users

it's an excellent simple example showing the use of:

specifically, here some explanations on the use of an ETag.

Some explanations on "what ETag is for?" here

I open Chrome, STRL-SHIFT.I (developer tools) , Networks, select "users", right-click, console / Headers/all (it took me a lot of clicking to find it...) and I see this:

Request URL:http://localhost:8080/PVRestRS/users
Request Method:GET
Status Code:304 Not Modified
Remote Address:
Referrer Policy:no-referrer-when-downgrade
Response Headers
view source
Date:Wed, 11 Oct 2017 00:31:57 GMT
Request Headers
view source
Accept-Encoding:gzip, deflate, br
Cookie:Idea-f3d396f=f1a96b31-981d-4574-a116-314fe061816e; __utma=111872281.364080227.1506531800.1506531800.1506531800.1; __utmc=111872281; __utmz=111872281.1506531800.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
If-Modified-Since:Tue, 19 Sep 2017 22:00:00 GMT
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

If I request http://localhost:8080/PVRestRS/users/pippo , I see also ETag:"version1" and (the second time only) If-None-Match:"version1"

"The If-None-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not exist. "

"1. If the response includes the "s-maxage" cache-control
directive, the cache MAY use that response in replying to a
subsequent request. But (if the specified maximum age has
passed) a proxy cache MUST first revalidate it with the origin
server, using the request-headers from the new request to allow
the origin server to authenticate the new request. (This is the
defined behavior for s-maxage.) If the response includes "s-
maxage=0", the proxy MUST always revalidate it before re-using

If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage directive also implies the semantics of the proxy-revalidate directive (see section 14.9.4), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. The s- maxage directive is always ignored by a private cache. "

This book is on my to-read list

The excellent article about JAX-RS on Java Magazine jan/feb 2016 by Abishek is available here

No comments: