search

opengeospatial / ets-ogcapi-processes10

Other
3 stars 3 forks source link

ETS expects unquoted strings while using `Accept: application/json` #55

Closed jerstlouis closed 9 months ago

jerstlouis commented 1 year ago

Describe the bug It seems that the ETS expects single value raw text outputs as unquoted strings, however it uses an Accept: header with application/json for making this request. This is inconsistent and causes compatibility problems with trying to respect OGC API Web Guidelines 10 - Flexible content negotiation and upcoming version 2.0.

Expected behavior If unquoted text values are expected, Accept: text/plain (for text) or application/octet-stream (for binary data) should be used (or at least not including an Accept: header at all).

bpross-52n commented 1 year ago

@jerstlouis I have created a fix for this (see #76). Could you maybe provide a test endpoint, so I can verify my fix?

jerstlouis commented 1 year ago

@bpross-52n We were testing this with our EchoProcess at https://maps.gnosis.earth/ogcapi/processes/echo

If this was preventing the ETS to pass, we might have set up a work-around to pass the compliance test. Which way was this fixed? Using Accept: text/plain or expecting string raw text outputs as quoted when requesting with Accept: application/json?

Right now POSTing to https://maps.gnosis.earth/ogcapi/processes/echo/execution:

{
  "process" : "https://maps.gnosis.earth/ogcapi/processes/echo",
  "inputs" : {
    "stringInput" : "Value1"
  },
  "response": "raw"
}

will return the string unquoted whether using Accept: application/json or not, as a result of that work-around.

If the fix is for the ETS to not use application/json, then that could be verified in the requests that is sent out.

Note that this is somewhat related to #60 (still open) and #61 (fixed?) whereas the number of outputs and the "raw" behavior will change depending on what outputs are to be returned.

bpross-52n commented 1 year ago

@jerstlouis We fixed it by leaving out the Accept header and then checking if the result contains the string input.

bpross-52n commented 9 months ago

@gfenoy I have created a pull request to fix this issue. However, the status document of the finished job returns the following link:

 {
    "title" : "Result location",
    "rel" : "results",
    "type" : "application/json",
    "href" : "http://.../results"
  }

Imho, the relation should be http://www.opengis.net/def/rel/ogc/1.0/results, see here: https://docs.ogc.org/is/18-062r2/18-062r2.html#toc16 Would you agree?

gfenoy commented 9 months ago

@gfenoy I have created a pull request to fix this issue. However, the status document of the finished job returns the following link:

 {
    "title" : "Result location",
    "rel" : "results",
    "type" : "application/json",
    "href" : "http://.../results"
  }

Imho, the relation should be http://www.opengis.net/def/rel/ogc/1.0/results, see here: https://docs.ogc.org/is/18-062r2/18-062r2.html#toc16 Would you agree?

I agree.