Please offer feedback for the following proposal:
https://github.com/geoserver/geoserver/wiki/GSIP-137
Kind Regards
Niels
Got a question … do we need both a resource and a dir endpoint?
/resource</path/to/resource[?]
- GET
Download a resource (json listing if directory)
html format produces human readable description, lists directory contents.
info format produces machine readable description, lists directory contents.
return 200 - POST
Upload a resource, create directories on the fly (fail if resource already existed).
Upload a zipfile to a directory is unpacked (is that useful?).
Upload a zipfile to a resource (such as icons.zip) is not unpacked.
return 201 - PUT
Upload a resource, create directories on the fly (overwrite if exists, fail if directory).
Zipfile handling as above.
return 200 (exists) 201 (new) - DELETE
Delete a resource (delete contents if directory)
return 200
Exceptions
- GET or DELETE for a resource that does not exist
return 404 - GET, POST, PUT or DELETE on directory
return 405 - POST for a resource that exists
return 405
···
On 13 January 2016 at 03:47, Niels Charlier <niels@anonymised.com> wrote:
Please offer feedback for the following proposal:
https://github.com/geoserver/geoserver/wiki/GSIP-137
Kind Regards
Niels
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Jody Garnett
Maybe it would make sense to have the query take a named argument in case we need to extend the API with additional parameters later later?
···
On 2016-01-13 09:44 AM, Jody Garnett wrote:
Got a question … do we need both a resource and a dir endpoint?
/resource</path/to/resource[?]
- GET
Download a resource (json listing if directory)
html format produces human readable description, lists directory contents.
info format produces machine readable description, lists directory contents.
return 200- POST
Upload a resource, create directories on the fly (fail if resource already existed).
Upload a zipfile to a directory is unpacked (is that useful?).
Upload a zipfile to a resource (such as icons.zip) is not unpacked.
return 201- PUT
Upload a resource, create directories on the fly (overwrite if exists, fail if directory).
Zipfile handling as above.
return 200 (exists) 201 (new)- DELETE
Delete a resource (delete contents if directory)
return 200Exceptions
- GET or DELETE for a resource that does not exist
return 404- GET, POST, PUT or DELETE on directory
return 405- POST for a resource that exists
return 405
/resource</path/to/resource[?metadata=]
Or just
/resource</path/to/resource[?metadata]
And the format is specified via HTTP content type negotiation.
--
Kevin Michael Smith
[<smithkm@anonymised.com>](mailto:smithkm@anonymised.com)
Hi Jody,
Fair enough, but there is only one thing missing in your proposal: what if you just want the metadata of a resource? What if you want to know when it was last modified or whether it is a directory / exists or not? It seems quite essential to me.
The zip file uploading was just an idea I had that I thought might be useful if people need to upload a whole directory, but I don’t know if that is a use case, it can be scrapped.
Regards
Niels
···
On 01/13/2016 06:44 PM, Jody Garnett wrote:
Got a question … do we need both a resource and a dir endpoint?
/resource</path/to/resource[?]
- GET
Download a resource (json listing if directory)
html format produces human readable description, lists directory contents.
info format produces machine readable description, lists directory contents.
return 200- POST
Upload a resource, create directories on the fly (fail if resource already existed).
Upload a zipfile to a directory is unpacked (is that useful?).
Upload a zipfile to a resource (such as icons.zip) is not unpacked.
return 201- PUT
Upload a resource, create directories on the fly (overwrite if exists, fail if directory).
Zipfile handling as above.
return 200 (exists) 201 (new)- DELETE
Delete a resource (delete contents if directory)
return 200Exceptions
- GET or DELETE for a resource that does not exist
return 404- GET, POST, PUT or DELETE on directory
return 405- POST for a resource that exists
return 405–
Jody GarnettOn 13 January 2016 at 03:47, Niels Charlier <niels@anonymised.com> wrote:
Please offer feedback for the following proposal:
https://github.com/geoserver/geoserver/wiki/GSIP-137
Kind Regards
Niels
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Agreed, I see the limitations - what do you think of Kevin’s idea of using a query string and avoid a parallel tree for metadata?
/resource</path/to/resource[?metadata=]
Could have:
/resource</path/to/resource[?metadata=html
/resource</path/to/resource[?metadata=json
···
On 13 January 2016 at 14:20, Niels Charlier <niels@anonymised.com> wrote:
Hi Jody,
Fair enough, but there is only one thing missing in your proposal: what if you just want the metadata of a resource? What if you want to know when it was last modified or whether it is a directory / exists or not? It seems quite essential to me.
The zip file uploading was just an idea I had that I thought might be useful if people need to upload a whole directory, but I don’t know if that is a use case, it can be scrapped.
Regards
NielsOn 01/13/2016 06:44 PM, Jody Garnett wrote:
Got a question … do we need both a resource and a dir endpoint?
/resource</path/to/resource[?]
- GET
Download a resource (json listing if directory)
html format produces human readable description, lists directory contents.
info format produces machine readable description, lists directory contents.
return 200- POST
Upload a resource, create directories on the fly (fail if resource already existed).
Upload a zipfile to a directory is unpacked (is that useful?).
Upload a zipfile to a resource (such as icons.zip) is not unpacked.
return 201- PUT
Upload a resource, create directories on the fly (overwrite if exists, fail if directory).
Zipfile handling as above.
return 200 (exists) 201 (new)- DELETE
Delete a resource (delete contents if directory)
return 200Exceptions
- GET or DELETE for a resource that does not exist
return 404- GET, POST, PUT or DELETE on directory
return 405- POST for a resource that exists
return 405
–
Jody Garnett
–
Jody Garnett
On 13 January 2016 at 03:47, Niels Charlier <niels@anonymised.com> wrote:
Please offer feedback for the following proposal:
https://github.com/geoserver/geoserver/wiki/GSIP-137
Kind Regards
Niels
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On 13 January 2016 at 22:48, Jody Garnett <jody.garnett@anonymised.com> wrote:
Agreed, I see the limitations - what do you think of Kevin's idea of using
a query string and avoid a parallel tree for metadata?
Isn't that what HEAD requests are for? And return the metadata in headers?
HEAD /resource/path/to/directory
Last-Modified: <timestamp>
Content-Type: application/x-directory
HEAD /resource/path/to/directory/file.png
ETag: <md5 hash>
Content-Length: 12345
Last-Modified: <timestamp>
Content-Type: image/png
Rob 
Correct, and tricky - wonder if our rest library supports that
Still human navigable html output our Json is not a bad thing.
···
On 13 January 2016 at 22:48, Jody Garnett <jody.garnett@anonymised.com> wrote:
Agreed, I see the limitations - what do you think of Kevin’s idea of using a query string and avoid a parallel tree for metadata?
Isn’t that what HEAD requests are for? And return the metadata in headers?
HEAD /resource/path/to/directory
Last-Modified:
Content-Type: application/x-directory
HEAD /resource/path/to/directory/file.png
ETag:
Content-Length: 12345
Last-Modified:
Content-Type: image/png
Rob
I agree with the general consensus that a single resource/endpoint should be sufficient
One implementation query: Is there any distinction between an empty directory and a directory that does not exist? (If so, why?).
If we are aiming for something that is ostensibly implementation-agnostic, I can’t see any compelling reasons for empty directories to exist, especially given that a POST will create any required directories on-the-fly. This approach would somewhat simplify navigation (since every listably directory is now guaranteed to terminate in a resource), but may be somewhat dependant on the underlying ResourceStore implementation (which I have not looked too thorougly into).
Torben
···
On Wed, Jan 13, 2016 at 3:01 PM, Robert Coup <robert.coup@anonymised.com> wrote:
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On 13 January 2016 at 22:48, Jody Garnett <jody.garnett@anonymised.com> wrote:
Agreed, I see the limitations - what do you think of Kevin’s idea of using a query string and avoid a parallel tree for metadata?
Isn’t that what HEAD requests are for? And return the metadata in headers?
HEAD /resource/path/to/directory
Last-Modified:
Content-Type: application/x-directory
HEAD /resource/path/to/directory/file.png
ETag:
Content-Length: 12345
Last-Modified:
Content-Type: image/png
Rob 
There is a difference at this moment. However, there is no way to create an empty directory from nothing. It can only exist if all of its children are deleted. I like your suggestion. That would imply that a directory is automatically deleted when it becomes empty. This goes back to the original resourcestore API though, not just the rest.
According to the current API, listing children won't make a difference between an empty or non-existing directory (both will return an empty list). However it won't be possible to write a resource to the path of an empty directory and getType() will result DIRECTORY instead of UNDEFINED.
This is something for a separate proposal to change resourcestore...
Regards
Niels
On 14-01-16 00:56, Torben Barsballe wrote:
I agree with the general consensus that a single resource/endpoint should be sufficient
One implementation query: Is there any distinction between an empty directory and a directory that does not exist? (If so, why?).
If we are aiming for something that is ostensibly implementation-agnostic, I can't see any compelling reasons for empty directories to exist, especially given that a POST will create any required directories on-the-fly. This approach would somewhat simplify navigation (since every listably directory is now guaranteed to terminate in a resource), but may be somewhat dependant on the underlying ResourceStore implementation (which I have not looked too thorougly into).Torben
On Wed, Jan 13, 2016 at 3:01 PM, Robert Coup <robert.coup@anonymised.com <mailto:robert.coup@anonymised.com>> wrote:
On 13 January 2016 at 22:48, Jody Garnett <jody.garnett@anonymised.com
<mailto:jody.garnett@anonymised.com>> wrote:Agreed, I see the limitations - what do you think of Kevin's
idea of using a query string and avoid a parallel tree for
metadata?Isn't that what HEAD requests are for? And return the metadata in
headers?HEAD /resource/path/to/directory
> Last-Modified: <timestamp>
> Content-Type: application/x-directoryHEAD /resource/path/to/directory/file.png
> ETag: <md5 hash>
> Content-Length: 12345
> Last-Modified: <timestamp>
> Content-Type: image/pngRob
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I've changed the proposal. I will research the HEAD proposal, but I'll support ?metadata anyway (as it is extendible)
Regards
Niels
On 14-01-16 00:03, Jody Garnett wrote:
Correct, and tricky - wonder if our rest library supports that
Still human navigable html output our Json is not a bad thing.
On Wed, Jan 13, 2016 at 3:02 PM Robert Coup <robert.coup@anonymised.com <mailto:robert.coup@anonymised.com>> wrote:On 13 January 2016 at 22:48, Jody Garnett <jody.garnett@anonymised.com
<mailto:jody.garnett@anonymised.com>> wrote:Agreed, I see the limitations - what do you think of Kevin's
idea of using a query string and avoid a parallel tree for
metadata?Isn't that what HEAD requests are for? And return the metadata in
headers?HEAD /resource/path/to/directory
> Last-Modified: <timestamp>
> Content-Type: application/x-directoryHEAD /resource/path/to/directory/file.png
> ETag: <md5 hash>
> Content-Length: 12345
> Last-Modified: <timestamp>
> Content-Type: image/pngRob
--
Jody Garnett
So Niels would you like people to review and vote on this now?
···
On 14 January 2016 at 08:38, Niels Charlier <niels@anonymised.com> wrote:
I’ve changed the proposal. I will research the HEAD proposal, but I’ll support ?metadata anyway (as it is extendible)
Regards
NielsOn 14-01-16 00:03, Jody Garnett wrote:
Correct, and tricky - wonder if our rest library supports that
Still human navigable html output our Json is not a bad thing.
On Wed, Jan 13, 2016 at 3:02 PM Robert Coup <robert.coup@anonymised.com> wrote:
–
–
Jody Garnett
–
Jody Garnett
On 13 January 2016 at 22:48, Jody Garnett <jody.garnett@anonymised.com> wrote:
Agreed, I see the limitations - what do you think of Kevin’s idea of using a query string and avoid a parallel tree for metadata?
Isn’t that what HEAD requests are for? And return the metadata in headers?
HEAD /resource/path/to/directory
Last-Modified:
Content-Type: application/x-directory
HEAD /resource/path/to/directory/file.png
ETag:
Content-Length: 12345
Last-Modified:
Content-Type: image/png
Rob
Yes
···
On 01/26/2016 09:48 PM, Jody Garnett wrote:
So Niels would you like people to review and vote on this now?
–
Jody GarnettOn 14 January 2016 at 08:38, Niels Charlier <niels@anonymised.com> wrote:
I’ve changed the proposal. I will research the HEAD proposal, but I’ll support ?metadata anyway (as it is extendible)
Regards
NielsOn 14-01-16 00:03, Jody Garnett wrote:
Correct, and tricky - wonder if our rest library supports that
Still human navigable html output our Json is not a bad thing.
On Wed, Jan 13, 2016 at 3:02 PM Robert Coup <robert.coup@anonymised.com> wrote:
On 13 January 2016 at 22:48, Jody Garnett <jody.garnett@anonymised.com> wrote:
Agreed, I see the limitations - what do you think of Kevin’s idea of using a query string and avoid a parallel tree for metadata?
Isn’t that what HEAD requests are for? And return the metadata in headers?
HEAD /resource/path/to/directory
Last-Modified:
Content-Type: application/x-directory
HEAD /resource/path/to/directory/file.png
ETag:
Content-Length: 12345Last-Modified:
Content-Type: image/png
Rob
–
–
Jody Garnett
On 14-01-16 00:01, Robert Coup wrote:
HEAD /resource/path/to/directory
> Last-Modified: <timestamp>
> Content-Type: application/x-directoryHEAD /resource/path/to/directory/file.png
> ETag: <md5 hash>
> Content-Length: 12345
> Last-Modified: <timestamp>
> Content-Type: image/pngRob
Some comments on the HEAD proposal.
* Last-modified is not a problem
* Content-type: there is no way to determine the mime-type of a resource. There are ways for files, but there is nothing in the resourcestore API that makes it possible (other than attempting to derive it from the data itself.)
But for directories, the HTTP header should specify the content-type of the content returned, which is XML, HTML or JSON, and not application/x-directory.
* Content-length: there is no way to determine the size of a resource (except for reading through the whole thing and counting)
So the way I see it, I am setting the datestamp in the header, so HEAD would be an alternative method to get last-modified info, but we'd still need the metadata operation to get the resource type.
Regards
Niels
Good research, you may be able to make a guess at content type based on filename extension - a bit risky but would allow people to see PNG files in their browser.
···
On 27 January 2016 at 03:06, Niels Charlier <niels@anonymised.com> wrote:
On 14-01-16 00:01, Robert Coup wrote:
HEAD /resource/path/to/directory
Last-Modified:
Content-Type: application/x-directoryHEAD /resource/path/to/directory/file.png
ETag:
Content-Length: 12345
Last-Modified:
Content-Type: image/pngRob
Some comments on the HEAD proposal.
Last-modified is not a problem
Content-type: there is no way to determine the mime-type of a resource. There are ways for files, but there is nothing in the resourcestore API that makes it possible (other than attempting to derive it from the data itself.)
But for directories, the HTTP header should specify the content-type of the content returned, which is XML, HTML or JSON, and not application/x-directory.Content-length: there is no way to determine the size of a resource (except for reading through the whole thing and counting)
So the way I see it, I am setting the datestamp in the header, so HEAD would be an alternative method to get last-modified info, but we’d still need the metadata operation to get the resource type.
Regards
Niels
–
Jody Garnett
Can we get a re-vote on this please? We have made changes.
On 26-01-16 22:41, Niels Charlier wrote:
Yes
On 01/26/2016 09:48 PM, Jody Garnett wrote:
So Niels would you like people to review and vote on this now?
--
Jody GarnettOn 14 January 2016 at 08:38, Niels Charlier <niels@anonymised.com <mailto:niels@anonymised.com>> wrote:
I've changed the proposal. I will research the HEAD proposal, but
I'll support ?metadata anyway (as it is extendible)Regards
NielsOn 14-01-16 00:03, Jody Garnett wrote:
Correct, and tricky - wonder if our rest library supports that
Still human navigable html output our Json is not a bad thing.
On Wed, Jan 13, 2016 at 3:02 PM Robert Coup
<robert.coup@anonymised.com
<mailto:robert.coup@anonymised.com>> wrote:On 13 January 2016 at 22:48, Jody Garnett
<jody.garnett@anonymised.com> wrote:Agreed, I see the limitations - what do you think of
Kevin's idea of using a query string and avoid a
parallel tree for metadata?Isn't that what HEAD requests are for? And return the
metadata in headers?HEAD /resource/path/to/directory
> Last-Modified: <timestamp>
> Content-Type: application/x-directoryHEAD /resource/path/to/directory/file.png
> ETag: <md5 hash>
> Content-Length: 12345
> Last-Modified: <timestamp>
> Content-Type: image/pngRob
-- -- Jody Garnett
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
In firefox - and I expect other browsers as well - this doesn't seem to be a problem, even without mime it is smart enough to know itself (from the extension probably).
Regards
Niels
On 27-01-16 17:04, Jody Garnett wrote:
Good research, you may be able to make a guess at content type based on filename extension - a bit risky but would allow people to see PNG files in their browser.
--
Jody GarnettOn 27 January 2016 at 03:06, Niels Charlier <niels@anonymised.com <mailto:niels@anonymised.com>> wrote:
On 14-01-16 00:01, Robert Coup wrote:
HEAD /resource/path/to/directory
> Last-Modified: <timestamp>
> Content-Type: application/x-directoryHEAD /resource/path/to/directory/file.png
> ETag: <md5 hash>
> Content-Length: 12345
> Last-Modified: <timestamp>
> Content-Type: image/pngRob
Some comments on the HEAD proposal.
* Last-modified is not a problem
* Content-type: there is no way to determine the mime-type of a
resource. There are ways for files, but there is nothing in the
resourcestore API that makes it possible (other than attempting to
derive it from the data itself.)
But for directories, the HTTP header should specify the
content-type of the content returned, which is XML, HTML or JSON,
and not application/x-directory.* Content-length: there is no way to determine the size of a
resource (except for reading through the whole thing and counting)So the way I see it, I am setting the datestamp in the header, so
HEAD would be an alternative method to get last-modified info, but
we'd still need the metadata operation to get the resource type.Regards
Niels