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