Thanks, so the paragraph states:
"The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate"
So, we need to do a couple of things:
1) Set the 'Location' header. I am not sure exactly what it should be in this case. This operation is not technically RESTful for a couple of reasons:
a) There is information built directly into the URI (the file.format) part
b) It results in resources be created elsewhere, ie under "...coverages/<coverage>", i am pretty sure this violates the semantics of PUT
2) Set the entity to something
I suggest we should do the following:
Set the returned entity should be the serialized coverages stores. The serialized store contains links to the coverages inside of it, so a client can proceed to get at the coverage (if it was created) as it sees fit.
We also set the Location header to be the uri of the coverage store.
What do you think?
Daniele Romagnoli wrote:
Hi,
On Fri, May 8, 2009 at 5:01 PM, Justin Deoliveira <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:
Right, after looking at the commits I noticed this was the case,
which is sort of a special case.
As per your comment:
>From [1] I see that the response should contain some info
> about the newly created resource.
Where exactly is this. I read the specification of the PUT method
and did not see such a reference.
Is the paragraph 10.2.2 - 201 Created
Daniele
-Justin
Daniele Romagnoli wrote:
Hi Justin,
I'm talking about the CoverageStoreFileResource which allows to
add a new coverage using the following syntax with PUT:
/workspaces/<ws>/coveragestores/<cs>/file[.<extension>]
I have noticed that when done, it returns a STATUS_CREATED in
the response.
Daniele
On Fri, May 8, 2009 at 3:55 PM, Justin Deoliveira
<jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>
<mailto:jdeolive@anonymised.com>> wrote:
hi Daniele,
Where exaclty is a 201 being set as the response code for a
PUT. The
semantic we are following for restconfig is to have PUT only
be used
to modify existing resources, therefore only returning a 200.
POST being used to create new resources on the other hand does
return a 201.. And it sets the Location header in the response,
pointing at the newly created resource. If you look at
ReflectiveResource.handlePost() you will see what I mean.
That said, we could use PUT to allow for creation of
resoures, it is
perfectly valid with regard to HTTP. What is your use case here?
-Justin
Daniele Romagnoli wrote:
Hi list,
I'm doing some work on improving restconfig.
When putting some resource via rest in geoserver, in case
everything goes ok, you will receive a response with a return
code = 201 --> handlePut does this: getResponse().setStatus(
Status.SUCCESS_CREATED );
>From [1] I see that the response should contain some info
about the newly created resource.
This can be achieved by properly setting an Entity in the
response, before setting Status.SUCCESS_CREATED.
Actually, geoserver simply set CREATED in the response
without
any additional info. Therefore, there isn't any information
about the just added layer.
Which type of information should we provide within the
response?
Any feedback is welcome.
Regards,
Daniele
[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
-- -------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY
circumstances! Your
production scanning environment may not be a perfect
world - but
thanks to
Kodak, there's a perfect scanner to get the job done!
With the
NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all
image processing features enabled.
http://p.sf.net/sfu/kodak-com
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
<mailto:Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-- Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-- -------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
-- Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.