The server accepts a number of GET and POST calls allowing to work remotely on a collection of FITS files containing images.
The server accepts a number of GET and POST calls allowing to work remotely, as an HTTP client, on a collection of FITS files containing images.
Technical aspects
-----------------
``serverWsgi`` is a bottle HTTP server. It accepts HTTP requests ( GET or POST ), extracts their parameters, converts
Technical aspects of our server
-------------------------------
The server is a bottle HTTP server. It accepts requests ( GET or POST ), extracts their parameters, converts
them from the string type to the appropriate type, delegates the processing to a dataManager layer from which
it receives the result to be sent back to the HTTP client in json form.
it receives the result to be sent back to the HTTP client in **json** form.
Conventions
-----------
* *Parameters* : each method GET or POST of an HTTP server expects zero, one or more parameters which are passed via a dictionary structure, i.e a sequence of ``key:value`` pairs. Of course this is true for yafitss, but in order to give the server the flavour of a domain specific language a convention for the names of the keys is adopted.\
Input parameters
----------------
Each method GET or POST of an HTTP server expects zero, one or more parameters which are passed via a dictionary structure, i.e a sequence of ``key:value`` pairs. Of course this is true for `yafitss`, but in order to give the server the flavour of a domain specific language a convention for the names of the keys is adopted.\
The list below enumerates those names, the types and the semantics of their associated values. Indeed types are not real types as in the usual sense since the values are always passed as strings; they are indications on the form those values should have:
* ``relFITSFilePath`` -- string -- the path of the FITS file of interest relative to the root directory of the FITS files
* ``iRA`` --int-- an indice along the RA axis
* ``iDEC`` --int-- an indice along the DEC axis
* ``RAinDD`` --float-- a right ascension expressed in decimal degrees
* ``DECinDD`` --float-- a declination expressed in decimal degrees
* ``iRA0`` --int-- the lower bound of a range of indices along the RA axis
* ``iRA1`` --int-- the upper bound of a range of indices along the RA axis
* ``iRAstep`` --int-- a step in a range of indices along the RA axis
* ``iDEC0`` --int-- the lower bound of a range of indices along the DEC axis
* ``iDEC1`` --int-- the upper bound of a range of indices along the DEC axis
* ``iDECstep`` --int-- a step in a range of indices along the DEC axis
* ``iFREQ`` --int-- an indice along the FREQ axis
* ``iFREQ0`` --int-- the lower bound of a range of indices along the FREQ axis
* ``iFREQ1`` --int-- the upper bound of a range of indices along the FREQ axis
* *Returned value* : each method returns a compound result with the following format : ``{"status": True of False, "message": <some text mostly used when something went wrong>, "result" : <the expected result or None>}``
* ``relFITSFilePath`` {String} the path of the FITS file of interest relative to the root directory of the FITS files
* ``iRA`` {uInt} an indice along the RA axis
* ``iDEC`` {uInt} an indice along the DEC axis
* ``RAinDD`` {Float} a right ascension expressed in decimal degrees
* ``DECinDD`` {Float} a declination expressed in decimal degrees
* ``iRA0`` {uInt} the lower bound of a range of indices along the RA axis
* ``iRA1`` {uInt} the upper bound of a range of indices along the RA axis
* ``iRAstep`` {uInt} a step in a range of indices along the RA axis
* ``iDEC0`` {uInt} the lower bound of a range of indices along the DEC axis
* ``iDEC1`` {uInt} the upper bound of a range of indices along the DEC axis
* ``iDECstep`` {uInt} a step in a range of indices along the DEC axis
* ``iFREQ`` {uInt} an indice along the FREQ axis
* ``iFREQ0`` {uInt} the lower bound of a range of indices along the FREQ axis
* ``iFREQ1`` {uInt} the upper bound of a range of indices along the FREQ axis
Returned values
---------------
API calls return systematically a compound result with the following format :
```
{
"status": True of False,
"message": <some text mostly used when something went wrong>,
"result" : <the expected result or None>
}
```
Consequently given a returned value stored in a variable `result`, a good practice is to proceed as follows:
* `if result["status"] :`
* retrieve the payload in `result["result"]`
* `else :`
* retrieve an error message in `result["message"]`
