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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
