SOS Endpoints vs. Bindings

The Problem

The SOS 4.0 introduced endpoints for every binding. Instead of directing request of different types, such as KVP using HTTP GET or POX using HTTP POST, to one endpoint, server.url/mySos/sos, the service now expects KVP request at server.url/mySOS/sos/kvp, POX requests at server.url/mySOS/sos/pox and SOAP requests at server.url/mySOS/sos/soap.

The reasoning behind this is that a client should know which binding he want to use and probably dosn't even support several bindings. Furthermore, detecting the request based on the content-type, was not needed here. The service does include these endpoints accordingly in the capabilities document in the DCP section:

<ows:Get xlink:href="http://localhost:8080/sos/sos/kvp"/>
<ows:Post xlink:href="http://localhost:8080/sos/sos/soap"/>
<ows:Post xlink:href="http://localhost:8080/sos/sos/pox"/>

This behaviour was reported as a bug https://bugzilla.52north.org/show_bug.cgi?id=848, because it limits the interoperability of clients. Since there is no single service endpoint the client has to add the binding to do the first GetCapabilities request. Also, having multiple ows:Post endpoints, the client has to find out which is the right one by either human intervention or by trial and error.

Plus/Positive

• Clear distinction between bindings makes service implementation easier. -- DanielNuest - 2013-03-13
• Humans can directly use the desired endpoint. -- DanielNuest - 2013-03-13
• ...

Negative

• Limited interoperability because a human has to decide which is the "correct" endpoint to use or to advertise. For example, in the SIR when a user (machine or human) discovers a sensor, which URL should the SIR return/harvest so that a client can automatically send a GetCapabilities request? -- DanielNuest - 2013-03-13
• Distinction between bindings makes client implementation harder (requires logic/testing by clients). -- DanielNuest - 2013-03-13
• No semantically interoperable definition of endpoints, information is hidden in the URL (i.e. it ends in "soap" or "kvp"). This is a problem of OWS Common?! -- DanielNuest - 2013-03-13

Ideas/Discussion

• The SOS should return helpful error messages in case a GET/POX request is send to .../sos/soap and vice versa. -- DanielNuest - 2013-03-13
• The SOS answer any type of GetCapabilities request at any endpoint and then the clients can figure out which endpoint is the correct one. -- DanielNuest - 2013-03-13 This seems like a good workaround for now. -- Main.Staschc - 2013-03-14
• Use HTTP redirects based on a common endpoint URL, e.g. server.url/mySos/sos. -- DanielNuest - 2013-03-13
• Contact OWS common standards working group about the ambiguity of ows:Post and potential shortcomings of capabilities documents. -- DanielNuest - 2013-03-13 May be the cleanest solution (at least with regard to OGC services and capabilities), but change request for OWS common may take quite long... There are already additional metadata elements available - how about taking a look how to add the information about SOAP, POX, ... there!?-- Main.Staschc - 2013-03-14
• In the basic configuration, URLs contain "sos" two times > could also be the shorter server.url/mySos/{kvp,pox,soap}. -- DanielNuest - 2013-03-13 +1 -- Main.Staschc - 2013-03-14
• The SOS should detect the correct binding based on the content type and HTTP headers. -- DanielNuest - 2013-03-13
  • Complications for this suggestion:
    • SOS 1.0.0 supports KVP via form submit ("KVP via POST")
    • ...