[Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

GeoServer GeoServer Developer
1

Here is the proposal from Niels:
https://github.com/geoserver/geoserver/wiki/GSIP-137

+1 the proposal has been revised addressing my earlier questions.

···

–
Jody Garnett

2

I have read the email thread and the proposal.

+1 on the new functionality.

···

On Tue, Jan 26, 2016 at 10:51 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is the proposal from Niels:
https://github.com/geoserver/geoserver/wiki/GSIP-137

+1 the proposal has been revised addressing my earlier questions.

–
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@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Alessio Fabiani
@alfa7691
Founder/Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 331 6233686

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

3

Hi Jody,
-1 for the moment, but only because the proposal is incomplete.

Bits that should be addressed before making it go forward:

  • Show the XML and JSON representations of the various resources and commands (are they properly interlinked via atom links, and what other information do they contain?). This is the most evident limitation of the proposal, as these are not implementation bits, but rightful part of the protocol you’re proposing to implement
  • Determine what happens if format is used against a file resource (that I assume we cannot transcode to another format), and what mime type will be returned for them (e.g., property files)
  • What is the metadata of a directory? I assume we can return metadata for a file too, but the proposal only mentions a format for directories
  • How does one tell apart the desire to upload a zip file, from one of uploading a directory to be unpacked? How does one create an emtpy directory?
  • I don’t claim to be a REST expert, but the POST usage seems strange… should’t POST be used only when the target resource position is determined by the server instead of by the caller? Some guidance here: http://restcookbook.com/HTTP%20Methods/put-vs-post/
  • HEAD requests for metadata seem a good idea

Finally, a general question, how is the resource work going to interact with the existing rest path mappers? What if for example one wants to upload via
the REST api some large data set to be configured, and make sure it’s going to be saved on disk instead of DBMS, because it needs to accessed
via random access and it’s in general very large?
My understanding is that JDBCConfig would only handle config and not data, but want to make sure.

Cheers
Andrea

···

On Tue, Jan 26, 2016 at 10:51 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is the proposal from Niels:
https://github.com/geoserver/geoserver/wiki/GSIP-137

+1 the proposal has been revised addressing my earlier questions.

–
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@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

4

Hi Andrea,

Thanks for your review.

On 27-01-16 10:48, Andrea Aime wrote:

Hi Jody,
-1 for the moment, but only because the proposal is incomplete.

Bits that should be addressed before making it go forward:
* Show the XML and JSON representations of the various resources and commands (are they properly interlinked via atom links, and what other information do they contain?). This is the most evident limitation of the proposal, as these are not implementation bits, but rightful part of the protocol you're proposing to implement

I added information on the XML format for metadata and directories (JSON is analogue).

* Determine what happens if format is used against a file resource (that I assume we cannot transcode to another format), and what mime type will be returned for them (e.g., property files)

Format is only used for metadata and directories. Otherwise, you get the actual file in its own format.

This is why I used to have two endpoints, because I found it weird to have the same GET for both the metadata with specified format or the file itself with server determined format; but the community preferred it this way.

* What is the metadata of a directory? I assume we can return metadata for a file too, but the proposal only mentions a format for directories

That was a mistake (changed), metadata is for any resource irrespective of type.

* How does one tell apart the desire to upload a zip file, from one of uploading a directory to be unpacked?

I removed the zip part from the proposal, because feedback told me there isn't really need for that atm.

How does one create an emtpy directory?

One does not create an empty directory. It is not part of the ResourceStore API, I had an extensive discussion about that with Jody last year who insisted it should not be possible. Directories are created on-the-fly.

* I don't claim to be a REST expert, but the POST usage seems strange... should't POST be used only when the target resource position is determined by the server instead of by the caller? Some guidance here: http://restcookbook.com/HTTP%20Methods/put-vs-post/

In that case, I should simply scrap the POST method from the proposal, the functionality is fully covered by PUT.
This is fine by mes.

* HEAD requests for metadata seem a good idea

Finally, a general question, how is the resource work going to interact with the existing rest path mappers? What if for example one wants to upload via
the REST api some large data set to be configured, and make sure it's going to be saved on disk instead of DBMS, because it needs to accessed
via random access and it's in general very large?
My understanding is that JDBCConfig would only handle _config_ and not data, but want to make sure.

The JDBCResourceStore has a configuration option for excluding directories. By default, the data upload directory is excluded, and any operation on this directory gets automatically forwarded to the FileSystem ResourceStore.

Regards
Niels

5

Thanks Andrea, all good feedback - these proposals end up being design documents after all.

I don’t think I know enough about how rest path mappers work to understand the difference between config and data. Internally the ResourceStoreAPI is used to access config, and a different GeoServerDataDirectory method is used to resolve relative URLs into a file reference for data access.

I had a similar question with respect to the difference between “config” and “catalog” - consider using this rest api in the styles folder - we want to access the “sld” and “font” files, but ignore the “xml” files used by the catalog configuration - since they are stored elsewhere/available by another rest api.

···

On 27 January 2016 at 01:48, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Jody,
-1 for the moment, but only because the proposal is incomplete.

Bits that should be addressed before making it go forward:

  • Show the XML and JSON representations of the various resources and commands (are they properly interlinked via atom links, and what other information do they contain?). This is the most evident limitation of the proposal, as these are not implementation bits, but rightful part of the protocol you’re proposing to implement
  • Determine what happens if format is used against a file resource (that I assume we cannot transcode to another format), and what mime type will be returned for them (e.g., property files)
  • What is the metadata of a directory? I assume we can return metadata for a file too, but the proposal only mentions a format for directories
  • How does one tell apart the desire to upload a zip file, from one of uploading a directory to be unpacked? How does one create an emtpy directory?
  • I don’t claim to be a REST expert, but the POST usage seems strange… should’t POST be used only when the target resource position is determined by the server instead of by the caller? Some guidance here: http://restcookbook.com/HTTP%20Methods/put-vs-post/
  • HEAD requests for metadata seem a good idea

Finally, a general question, how is the resource work going to interact with the existing rest path mappers? What if for example one wants to upload via
the REST api some large data set to be configured, and make sure it’s going to be saved on disk instead of DBMS, because it needs to accessed
via random access and it’s in general very large?
My understanding is that JDBCConfig would only handle config and not data, but want to make sure.

Cheers
Andrea

–
Jody Garnett

On Tue, Jan 26, 2016 at 10:51 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is the proposal from Niels:
https://github.com/geoserver/geoserver/wiki/GSIP-137

+1 the proposal has been revised addressing my earlier questions.

–
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

–

==
GeoServer Professional Services from the experts! Visit

http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

6

Andrea, have I addressed your questions well enough with my changes?

Do we agree on removing POST altogether (have not yet changed this in the proposal yet)?

Niels

On 27-01-16 11:29, Niels Charlier wrote:

Hi Andrea,

Thanks for your review.

On 27-01-16 10:48, Andrea Aime wrote:

Hi Jody,
-1 for the moment, but only because the proposal is incomplete.

Bits that should be addressed before making it go forward:
* Show the XML and JSON representations of the various resources and
commands (are they properly interlinked via atom links, and what other
information do they contain?). This is the most evident limitation of
the proposal, as these are not implementation bits, but rightful part
of the protocol you're proposing to implement

I added information on the XML format for metadata and directories (JSON
is analogue).

* Determine what happens if format is used against a file resource
(that I assume we cannot transcode to another format), and what mime
type will be returned for them (e.g., property files)

Format is only used for metadata and directories. Otherwise, you get the
actual file in its own format.

This is why I used to have two endpoints, because I found it weird to
have the same GET for both the metadata with specified format or the
file itself with server determined format; but the community preferred
it this way.

* What is the metadata of a directory? I assume we can return metadata
for a file too, but the proposal only mentions a format for directories

That was a mistake (changed), metadata is for any resource irrespective
of type.

* How does one tell apart the desire to upload a zip file, from one of
uploading a directory to be unpacked?

I removed the zip part from the proposal, because feedback told me there
isn't really need for that atm.

How does one create an emtpy directory?

One does not create an empty directory. It is not part of the
ResourceStore API, I had an extensive discussion about that with Jody
last year who insisted it should not be possible. Directories are
created on-the-fly.

* I don't claim to be a REST expert, but the POST usage seems
strange... should't POST be used only when the target resource
position is determined by the server instead of by the caller? Some
guidance here: http://restcookbook.com/HTTP%20Methods/put-vs-post/

In that case, I should simply scrap the POST method from the proposal,
the functionality is fully covered by PUT.
This is fine by mes.

* HEAD requests for metadata seem a good idea

Finally, a general question, how is the resource work going to
interact with the existing rest path mappers? What if for example one
wants to upload via
the REST api some large data set to be configured, and make sure it's
going to be saved on disk instead of DBMS, because it needs to accessed
via random access and it's in general very large?
My understanding is that JDBCConfig would only handle _config_ and not
data, but want to make sure.

The JDBCResourceStore has a configuration option for excluding
directories. By default, the data upload directory is excluded, and any
operation on this directory gets automatically forwarded to the
FileSystem ResourceStore.

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

7

Hi Niels,
I’m sorry, still haven’t had time to review your changes.

I’ll be fully packed till evening today too, but I’ll make sure to review everything during
the weekend

Cheers
Andrea

···

On Fri, Jan 29, 2016 at 1:57 PM, Niels Charlier <niels@anonymised.com> wrote:

Andrea, have I addressed your questions well enough with my changes?

Do we agree on removing POST altogether (have not yet changed this in
the proposal yet)?

Niels

On 27-01-16 11:29, Niels Charlier wrote:

Hi Andrea,

Thanks for your review.

On 27-01-16 10:48, Andrea Aime wrote:

Hi Jody,
-1 for the moment, but only because the proposal is incomplete.

Bits that should be addressed before making it go forward:

  • Show the XML and JSON representations of the various resources and
    commands (are they properly interlinked via atom links, and what other
    information do they contain?). This is the most evident limitation of
    the proposal, as these are not implementation bits, but rightful part
    of the protocol you’re proposing to implement
    I added information on the XML format for metadata and directories (JSON
    is analogue).
  • Determine what happens if format is used against a file resource
    (that I assume we cannot transcode to another format), and what mime
    type will be returned for them (e.g., property files)
    Format is only used for metadata and directories. Otherwise, you get the
    actual file in its own format.

This is why I used to have two endpoints, because I found it weird to
have the same GET for both the metadata with specified format or the
file itself with server determined format; but the community preferred
it this way.

  • What is the metadata of a directory? I assume we can return metadata
    for a file too, but the proposal only mentions a format for directories
    That was a mistake (changed), metadata is for any resource irrespective
    of type.
  • How does one tell apart the desire to upload a zip file, from one of
    uploading a directory to be unpacked?
    I removed the zip part from the proposal, because feedback told me there
    isn’t really need for that atm.

How does one create an emtpy directory?
One does not create an empty directory. It is not part of the
ResourceStore API, I had an extensive discussion about that with Jody
last year who insisted it should not be possible. Directories are
created on-the-fly.

  • I don’t claim to be a REST expert, but the POST usage seems
    strange… should’t POST be used only when the target resource
    position is determined by the server instead of by the caller? Some
    guidance here: http://restcookbook.com/HTTP%20Methods/put-vs-post/
    In that case, I should simply scrap the POST method from the proposal,
    the functionality is fully covered by PUT.
    This is fine by mes.
  • HEAD requests for metadata seem a good idea

Finally, a general question, how is the resource work going to
interact with the existing rest path mappers? What if for example one
wants to upload via
the REST api some large data set to be configured, and make sure it’s
going to be saved on disk instead of DBMS, because it needs to accessed
via random access and it’s in general very large?
My understanding is that JDBCConfig would only handle config and not
data, but want to make sure.
The JDBCResourceStore has a configuration option for excluding
directories. By default, the data upload directory is excluded, and any
operation on this directory gets automatically forwarded to the
FileSystem ResourceStore.

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

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

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

8

On Fri, Jan 29, 2016 at 1:57 PM, Niels Charlier <niels@anonymised.com> wrote:

Andrea, have I addressed your questions well enough with my changes?

Yes and no. I can now see the representation, and confirm the answer to
"are they properly interlinked via atom links?" has a negative answer.

The ResourceMetadata xml representation should be follow the same resource
interlinking
approach as our main REST API, for example:

<ResourceMetaData>
      <name> nameOfFile </name>
      <parent>
          <path>path/to/parent</path>
          <atom:link xmlns:atom="http://www.w3.org/2005/Atom&quot;
rel="alternate" href="
http://localhost:8080/geoserver/rest/resource/path/to/parent.xml&quot;
type="application/xml"/>
       <parent>
      <lastModified> date </lastModified>
      <type> UNDEFINED | RESOURCE | DIRECTORY </type>
  </ResourceMetaData>

and the same should be valid for the json representation.
Same goes for the directory representation.

Do we agree on removing POST altogether (have not yet changed this in
the proposal yet)?

I'd remove POST, two ways to do exactly the same things seem redundant to
me,
not sure what other think... maybe the API is easier to use if one does not
have to remember whether to use PUT or POST? :slight_smile:

There are questions that still do not get an answer in the proposal, see as
follows:

* Determine what happens if format is used against a file resource
> (that I assume we cannot transcode to another format), and what mime
> type will be returned for them (e.g., property files)
Format is only used for metadata and directories. Otherwise, you get the
actual file in its own format.

Yes, but what mime type do we get? You have to return one right?
I understand it's hard to guess the mime type of a random file, so one
could say
that it's going to be "application/octet-stream", which is the most generic.
Or maybe you want to apply some special treatment to well known extensions,
like .properties and .xml or .sld.
I see that Java 7 has this useful API, maybe it can be used for a guess?
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#probeContentType(java.nio.file.Path)

In any case, the proposal should state something in this respect.

Writing the above I actually raised one more question: what happens if
someone
goes and chances configuration files using the resource REST api?
It's ok to say "it's store implementation dependent", but at least we
should make
a statement on that (otherwise people will start assuming that the behavior
of one store is actually valid for all stores).

Oh, and one final question, I see it's a proposal, I'm assuming this means
these
new endpoints will be folded in the main rest API, instead of being a
community
module, right?
So is it going to be implemented using the same library as the main REST
api?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

9

On Wed, Jan 27, 2016 at 5:11 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Thanks Andrea, all good feedback - these proposals end up being design
documents after all.

I don't think I know enough about how rest path mappers work to
understand the difference between config and data. Internally the
ResourceStoreAPI is used to access config, and a different
GeoServerDataDirectory method is used to resolve relative URLs into a file
reference for data access.

Path mappers are used for data uploads, and they can tell you that certain
data
must be placed outside of the data directory (e.g., in a large share for
raster data).
Will this implementation consider that case?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

10

Modified. Fair enough, done. I didn’t want anything based on Files, because I don’t want to force caching it as a file just to determine the mime type. But I have found a way that uses both filename and content: I have added to the proposal that content type will be guessed in this manner. I don’t understand your point. The REST API will give to administrators the same control over the resource store as they would have through the file system with a regular data directory. Yes. Regards Niels

···

On 30-01-16 12:08, Andrea Aime wrote:

The ResourceMetadata xml representation should be follow the same resource interlinking
approach as our main REST API, for example:

I’d remove POST, two ways to do exactly the same things seem redundant to me,
not sure what other think… maybe the API is easier to use if one does not
have to remember whether to use PUT or POST? :slight_smile:

I see that Java 7 has this useful API, maybe it can be used for a guess?
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#probeContentType%28java.nio.file.Path%29

		String mimeType = URLConnection.guessContentTypeFromName(resource.name());
                if (MediaType.APPLICATION_OCTET_STREAM.getName().equals(mimeType)) {
                    try (InputStream is = new BufferedInputStream(resource.in())) {
                        mimeType = URLConnection.guessContentTypeFromStream(is);
                    } catch (IOException e) {
                        //do nothing, keep at application/octet-stream
                    }
                }

Writing the above I actually raised one more question: what happens if someone
goes and chances configuration files using the resource REST api?
It’s ok to say “it’s store implementation dependent”, but at least we should make
a statement on that (otherwise people will start assuming that the behavior
of one store is actually valid for all stores).

Oh, and one final question, I see it’s a proposal, I’m assuming this means these
new endpoints will be folded in the main rest API, instead of being a community
module, right?
So is it going to be implemented using the same library as the main REST api?

11

On Tue, Feb 2, 2016 at 11:26 AM, Niels Charlier <niels@anonymised.com> wrote:

Writing the above I actually raised one more question: what happens if
someone
goes and chances configuration files using the resource REST api?
It's ok to say "it's store implementation dependent", but at least we
should make
a statement on that (otherwise people will start assuming that the behavior
of one store is actually valid for all stores).

I don't understand your point. The REST API will give to administrators
the same control over the resource store as they would have through the
file system with a regular data directory.

Yes and no, and imho this should be clarified.

With the data directory we have a clear position, if one modifies the xml
configuration files on disk, nothing
happens, GeoServer will not notice, unless a reload is forced or it's
otherwise specified (e.g., control-flow
configuraton file, or other flies that are under a watcher).
However if I reload I have a guarantee that the config file changes will be
picked up

But if you have JDBCConfig and JDBCResourceStore then things become
somewhat more complicated...
the xml config file is saved in the resource store I assume, but I assume
JDBCConfig will not notice at all,
since it has its own database, and thus a "reload" will do nothing...
or will it be notified and will change the config db contents?

If you don't want to get into those details I'm happy to just have a
statement stating that
changing a config file has an undefined behavior, and then have some docs
to warn the users of that.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

12

Hmmm, I still find it difficult to understand your point.

If you are using JDBCConfig, the catalog .xml files become meaningless, are ignored and changing them never has any effect. There is no difference there whether you are using jdbcstore or not.

As far as I see it, changing a config resource with the REST API or on the file system is identical.

Regards
Niels

On 02-02-16 11:44, Andrea Aime wrote:

On Tue, Feb 2, 2016 at 11:26 AM, Niels Charlier <niels@anonymised.com <mailto:niels@anonymised.com>> wrote:

    Writing the above I actually raised one more question: what
    happens if someone
    goes and chances configuration files using the resource REST api?
    It's ok to say "it's store implementation dependent", but at
    least we should make
    a statement on that (otherwise people will start assuming that
    the behavior
    of one store is actually valid for all stores).

    I don't understand your point. The REST API will give to
    administrators the same control over the resource store as they
    would have through the file system with a regular data directory.

Yes and no, and imho this should be clarified.

With the data directory we have a clear position, if one modifies the xml configuration files on disk, nothing
happens, GeoServer will not notice, unless a reload is forced or it's otherwise specified (e.g., control-flow
configuraton file, or other flies that are under a watcher).
However if I reload I have a guarantee that the config file changes will be picked up

But if you have JDBCConfig and JDBCResourceStore then things become somewhat more complicated...
the xml config file is saved in the resource store I assume, but I assume JDBCConfig will not notice at all,
since it has its own database, and thus a "reload" will do nothing...
or will it be notified and will change the config db contents?

If you don't want to get into those details I'm happy to just have a statement stating that
changing a config file has an undefined behavior, and then have some docs to warn the users of that.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

-------------------------------------------------------

13

Geoserver will kind of notice in both cases - icons are cached so will not pick up on a change unless we add a watcher (or until as you say the next reload).

Things like security that already have a watcher will be noticed in both cases.

We should put this off until we look at notification - chances are we will introduce notification which will benefit both JDBC and File resource store implementations.

···

On Tue, Feb 2, 2016 at 11:26 AM, Niels Charlier <niels@anonymised.com> wrote:

I don’t understand your point. The REST API will give to administrators the same control over the resource store as they would have through the file system with a regular data directory.

Writing the above I actually raised one more question: what happens if someone

goes and chances configuration files using the resource REST api?
It’s ok to say “it’s store implementation dependent”, but at least we should make
a statement on that (otherwise people will start assuming that the behavior
of one store is actually valid for all stores).

Yes and no, and imho this should be clarified.

With the data directory we have a clear position, if one modifies the xml configuration files on disk, nothing
happens, GeoServer will not notice, unless a reload is forced or it’s otherwise specified (e.g., control-flow
configuraton file, or other flies that are under a watcher).
However if I reload I have a guarantee that the config file changes will be picked up

But if you have JDBCConfig and JDBCResourceStore then things become somewhat more complicated…
the xml config file is saved in the resource store I assume, but I assume JDBCConfig will not notice at all,
since it has its own database, and thus a “reload” will do nothing…
or will it be notified and will change the config db contents?

If you don’t want to get into those details I’m happy to just have a statement stating that
changing a config file has an undefined behavior, and then have some docs to warn the users of that.

Cheers

Andrea

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

14

On Tue, Feb 2, 2016 at 11:54 AM, Niels Charlier <niels@anonymised.com> wrote:

Hmmm, I still find it difficult to understand your point.

If you are using JDBCConfig, the catalog .xml files become meaningless,
are ignored and changing them never has any effect. There is no difference
there whether you are using jdbcstore or not.

As far as I see it, changing a config resource with the REST API or on the
file system is identical.

You are right... it's just that my original expectation was different,
since the two plugins are developed
by the same company I was (wrongly) assuming there would be some
integration/synergy between them.

No problem. +1 on the proposal in its current state.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

15

+1. Looking pretty good. Observations:

- Instead of metadata, it would be (arguably) more RESTful to support a HEAD operation. You have a header for Last-Modified, could add an X-Parent and X-Type, and name could be deduced from the URL. Or is the need for custom HTTP headers a red flag? (Not to mention the problems passing these through the stack.) Andrea raised the issue of HEAD and I do not recall seeing a response. Please state why you are not using HEAD. The core need I see is for directory traversal. I dislike parsing URLs to find a parent resource, but would that be more RESTful? Is the use of a metadata parameter a REST best practice?

- I am not sure that "operation" is the right word to GET "metadata", but I do not have an alternative. Metadata is not a format. "aspect", perhaps? Do we have anything similar in the existing API?

- Are resources strictly a tree? Can you have loops? Unix filesystems support this with hard links, in which there can be multiple paths for a single resource, all canonical. What does this mean for recursive deletion? It might be worth documenting your assumptions.

- Should this API support parameters from the main REST API like "recurse" and "quietOnNotFound"? There may be more. I am not saying that I like these parameters; I think this GSIP is a bit more RESTful. I just thought that users might expect them. Please skim the existing REST API as a final review with consistency in mind.

- Should these be lowercase? Uppercase looks out of place:
"<type> UNDEFINED | RESOURCE | DIRECTORY </type>"

- Document that POST returns a 405.

Kind regards,
Ben.

On 27/01/16 10:51, Jody Garnett wrote:

Here is the proposal from Niels:
https://github.com/geoserver/geoserver/wiki/GSIP-137

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

16

HI Ben,

Thanks for your review!

On 02/02/2016 08:37 PM, Ben Caradoc-Davies wrote:

+1. Looking pretty good. Observations:

Cool thanks, that makes it approved then.

- Instead of metadata, it would be (arguably) more RESTful to support a HEAD operation. You have a header for Last-Modified, could add an X-Parent and X-Type, and name could be deduced from the URL. Or is the need for custom HTTP headers a red flag? (Not to mention the problems passing these through the stack.) Andrea raised the issue of HEAD and I do not recall seeing a response. Please state why you are not using HEAD. The core need I see is for directory traversal. I dislike parsing URLs to find a parent resource, but would that be more RESTful? Is the use of a metadata parameter a REST best practice?

I did send an email about the HEAD operation. Last-modified will be supported. I did not actually think of using custom http headers for the other fields. That is interesting. We can support both.

- I am not sure that "operation" is the right word to GET "metadata", but I do not have an alternative. Metadata is not a format. "aspect", perhaps? Do we have anything similar in the existing API?

I guess I can change it back to metadata=1 as it was in an earlier version if that is preferred, but I found it more consistent with the other requests this way. The way I see it, getting the metadata is a different operation than getting the data.

- Are resources strictly a tree? Can you have loops? Unix filesystems support this with hard links, in which there can be multiple paths for a single resource, all canonical. What does this mean for recursive deletion? It might be worth documenting your assumptions.

I don't know if I would call it "supported". It is technically possible, but strongly discouraged, and most modern Linuxes make it impossible to hard link directories to prevent it from happening. I believe last time I encountered this about 10 years ago, my delete operation got into an infinitive loop and started to delete my whole hard drive. The ResourceStore API definitely doesn't support it, it would regard paths of different sizes as different resources. The same for JDBCstore, you can technically create such a loop directly into the database but I would regard that as a corruption of the database's integrity (and there are many other ways in which one could corrupt the resource database if an evil or stupid person manipulated the DBMS directly).

- Should this API support parameters from the main REST API like "recurse" and "quietOnNotFound"? There may be more. I am not saying that I like these parameters; I think this GSIP is a bit more RESTful. I just thought that users might expect them. Please skim the existing REST API as a final review with consistency in mind.

recurse -> delete, move and copy on a directory is always recursive. The alternative is failing, but I see little need to force people to
specify this explicitly. If you do an operation on a directory that is generally what you intend to do. That is different to someone wanting to delete a store who might not realise he is deleting layers. I dunno, if people still want it I can easily implement this.

quietOnNotFound -> I'd never log exceptions when someone requests a resource that is not found. That is not an error, it is still a valid request. Simply return 404

- Should these be lowercase? Uppercase looks out of place:
"<type> UNDEFINED | RESOURCE | DIRECTORY </type>"

Yeah that is the internal representation, I can easily convert it to lowercase of course.

- Document that POST returns a 405.

ok.

Regards
Niels

17

On 3 February 2016 at 23:46, Niels Charlier <niels@anonymised.com> wrote:

> - Instead of metadata, it would be (arguably) more RESTful to support
> a HEAD operation. You have a header for Last-Modified, could add an
> X-Parent and X-Type, and name could be deduced from the URL. Or is the
> need for custom HTTP headers a red flag? (Not to mention the problems
> passing these through the stack.) Andrea raised the issue of HEAD and
> I do not recall seeing a response. Please state why you are not using
> HEAD. The core need I see is for directory traversal. I dislike
> parsing URLs to find a parent resource, but would that be more
> RESTful? Is the use of a metadata parameter a REST best practice?

I did send an email about the HEAD operation. Last-modified will be
supported. I did not actually think of using custom http headers for the
other fields. That is interesting. We can support both.

fyi, the "X-" prefix for custom headers is not the recommended approach any
more... http://tools.ietf.org/html/rfc6648#section-3

*Recommendations for Creators of New Parameters*

Creators of new parameters to be used in the context of

application protocols:
1. SHOULD assume that all parameters they create might
become standardized, public, commonly deployed, or usable across multiple
implementations.
2. SHOULD employ meaningful parameter names that they have reason
to believe are currently unused.
3. SHOULD NOT prefix their parameter names with "X-" or
similar constructs.

Rob :slight_smile:

18

Page updated, totalling up the numbers has this one passed:

https://github.com/geoserver/geoserver/wiki/GSIP-137

Hopefully the work can get in before the Feb 18th cut-off.

···

On 26 January 2016 at 13:51, Jody Garnett <jody.garnett@anonymised.com> wrote:

Here is the proposal from Niels:
https://github.com/geoserver/geoserver/wiki/GSIP-137

+1 the proposal has been revised addressing my earlier questions.

–
Jody Garnett

–
Jody Garnett

19

On 09/02/16 08:14, Robert Coup wrote:

fyi, the "X-" prefix for custom headers is not the recommended approach any
more... http://tools.ietf.org/html/rfc6648#section-3
*Recommendations for Creators of New Parameters*
Creators of new parameters to be used in the context of

application protocols:
1. SHOULD assume that all parameters they create might
become standardized, public, commonly deployed, or usable across multiple
implementations.
2. SHOULD employ meaningful parameter names that they have reason
to believe are currently unused.
3. SHOULD NOT prefix their parameter names with "X-" or
similar constructs.

Rob :slight_smile:

Thanks for the link, Rob. That is a good point. I felt that custom headers are a bad idea and was soliciting suggestions for best-practices for RESTful directory traversal with HEAD to find a parent. Surely someone has tried this? Or is it an acceptable practice to assume that HTTP URLs can be parsed to remove trailing path elements?

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

20

I think custom headers are fine, it’s just that if someone is using them in practice they’ll know to expect them :slight_smile:

RESTful directories (IMO) should be self-documenting: the parent of /a/b/c is /a/b and so on…

AFAICT there’s nothing special in the metadata proposal that couldn’t be dealt with via:
Content-Type: application/directory (or of a file)
Last-Modified:

(sure, XML/JSON for consistency/other reasons is fine).

Whether it’s a file or directory, the parent resource comes from the next path segment…

Rob :slight_smile:

···

On 10 February 2016 at 15:24, Ben Caradoc-Davies <ben@anonymised.com> wrote:

On 09/02/16 08:14, Robert Coup wrote:

fyi, the “X-” prefix for custom headers is not the recommended approach any
more… http://tools.ietf.org/html/rfc6648#section-3
Recommendations for Creators of New Parameters
Creators of new parameters to be used in the context of

application protocols:

  1. SHOULD assume that all parameters they create might
    become standardized, public, commonly deployed, or usable across multiple
    implementations.
  2. SHOULD employ meaningful parameter names that they have reason
    to believe are currently unused.
  3. SHOULD NOT prefix their parameter names with “X-” or
    similar constructs.

Rob :slight_smile:

Thanks for the link, Rob. That is a good point. I felt that custom headers are a bad idea and was soliciting suggestions for best-practices for RESTful directory traversal with HEAD to find a parent. Surely someone has tried this? Or is it an acceptable practice to assume that HTTP URLs can be parsed to remove trailing path elements?

Kind regards,

–
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

–

Chief Technical Officer Koordinates

+44 759 987 3480 / koordinates.com / @koordinates