As soon as I do a POST, I have to have code that produces and sends content
with that POST. So, given my examples, you can no longer just use "urlwrite"
or "download.file". So now I have to maintain my own code. Or put it another
way, I was able to send to this list two URLs in an email that anyone could put
in their browser and they worked, this would not be a case with a POST. Or
for another example, here is a web site that was developed by a scientist who
knows only a little html:
http://www.pfeg.noaa.gov/~cwilson/bloom/BW_14.html
Would have been much harder to do if a POST was involved, simple to do since
the URL completely defines the request (and that ERDDAP understands the time
"last" to get the latest data).
On a more theoretical basis, POSTs are neither idempotent nor safe. There
clearly are situations where POSTs are needed, but Bob Simons has shown in
ERDDAP that in terms of read-only data services, a lot can be done without it.
Part of this is ERDDAP doesn't try to be everything to everybody, like many
OGC services (the 80% solution I have been ribbed about). Once you try to
include the most general cases, as does OGC commonly, then you need the more
complicated service. The end result is that the services that don't need those
complications are burdened with them anyway.
I will repeat our little mantra - simple and fast.
-Roy
On Jul 1, 2012, at 12:29 PM, Gerry Creager wrote:
> So Roy, let me see if I understand what you want:
> A RESTful application, but with limits on the extent of REST, such that you
> solely use GET but not POST?
>
> Legitimate question, and I may have missed context here: What's the issue
> with POST? It almost seems like you're trying to shoehorn a SOAP application
> into a RESTful framework, which we CAN do, but my experience suggests that
> wrestling the input params into a SOAP app leads to one-off use cases (one of
> my biggest gripes about SOAP). Thus, your plan to use GET (ie., REST) makes
> great sense to me, but why lose the utility of POST in the process?
>
> Thanks gerry
>
> On Sun, Jul 1, 2012 at 2:00 PM, Roy Mendelssohn <roy.mendelssohn@xxxxxxxx>
> wrote:
>
> On Jul 1, 2012, at 11:25 AM, Dennis Heimbigner wrote:
>
> > Roy-
> >
> > > ... One comment. I think you misunderstood my point about
> > > Matlab and R. I am not interested in Matlab specific
> > > implementations. The point was because the URL completely
> > > defines the request, I can implement scripts in any application
> > > that can send an URL and receive a file in terms of functions
> > > built-in to that application - that is my clients do not break as
> > > the application or operating system change.
> >
> > Not quite sure I understand. This phrase "...receive a file in
> > terms of functions built-in to that application" sounds
> > like you are creating an association between functions defined
> > on the client side and functions defined on the server side.
> > Can you elaborate?
>
> Okay, let's start with my original example. Put the following URL in your
> browser:
>
> http://coastwatch.pfeg.noaa.gov/erddap/griddap/erdBAsstamday.nc?sst[(2010-01-16T12:00:00Z):1:(2010-01-16T12:00:00Z)][(0.0):1:(0.0)][(30):1:(50.0)][(220):1:(240.0)]
>
> You just downloaded a netcdf file that was a subset of a larger virtual file.
> And try this one:
>
> http://coastwatch.pfeg.noaa.gov/erddap/griddap/erdBAsstamday.png?sst[(2010-01-16T12:00:00Z):1:(2010-01-16T12:00:00Z)][(0.0):1:(0.0)][(30):1:(50.0)][(220):1:(240.0)]
>
> You just got a png of the same data. These URL's completely define the
> service request, in this case the service is ERDDAP. So given that, any
> application that has a command that can send an URL and receive a file, can
> use the service. In the case of Matlab that command is "urlwrite". In case
> of R, that command is "download.file". So now we can develop scripts for
> Matlab and R that are based on the commands "urlwrite" or "download.file",
> can use the service by just constructing the proper URL, and therefore every
> command in the script is a command built into that application, so the
> updating and maintenance of that command is the job of the application
> developer.
>
> Just to either make the point clearer or to muddy the waters (you never
> know), here is a brief matlab script that uses the command (it does use the
> m_map toolbox for mapping but that is separate from the service):
>
> > link='http://coastwatch.pfeg.noaa.gov/erddap/griddap/erdBAsstamday.mat?sst[(2010-01-16T12:00:00Z):1:(2010-01-16T12:00:00Z)][(0.0):1:(0.0)][(30):1:(50.0)][(220):1:(240.0)]';
> > F=urlwrite(link,'cwatch.mat');
> > load('-MAT',F);ssta=reshape(erdBAsstamday.sst,201,201);
> > pcolor(double(ssta));shading flat;colorbar;
> > latitude= erdBAsstamday.latitude;
> > longitude= erdBAsstamday.longitude;
> > [Plg,Plt]=meshgrid(longitude,latitude);
> > m_proj('mercator','lon',[-140 -115], 'lat', [30 50]);
> > m_pcolor(Plg-360,Plt,double(ssta));
> > shading flat;
> > m_coast('patch',[.7 .7 .7]);
> > m_grid;
> > colorbar;
> >
>
>
> And similarly in R:
>
> > library(ncdf4)
> > library(lattice)
> > download.file(url="http://coastwatch.pfeg.noaa.gov/erddap/griddap/erdBAsstamday.nc?sst[(2010-01-16T12:00:00Z):1:(2010-01-16T12:00:00Z)][(0.0):1:(0.0)][(30):1:(50.0)][(220):1:(240.0)]",
> > destfile="AGssta.nc",mode='wb')
> > AGsstaFile<-nc_open('AGssta.nc')
> > sst<-ncvar_get(AGsstaFile,'sst',start=c(1,1,1,1),count=c(-1,-1,-1,-1))
> > lonval<-ncvar_get(AGsstaFile,'longitude',1,-1)
> > latval<-ncvar_get(AGsstaFile,'latitude',1,-1)
> > image(lonval,latval,sst,col=rainbow(30))
> >
>
>
> To see this idea taken to a further level, see
> http://coastwatch.pfeg.noaa.gov/xtracto/
>
> -Roy
>
>
>
> **********************
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **********************
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> 1352 Lighthouse Avenue
> Pacific Grove, CA 93950-2097
>
> e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
> voice: (831)-648-9029
> fax: (831)-648-8440
> www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
**********************
"The contents of this message do not reflect any position of the U.S.
Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097
e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
