Date: Thu, 28 Mar 2024 16:02:44 +0000 (UTC)
Message-ID: <1066168859.1117.1711641764284@9b64b402ade9>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_1116_518999958.1711641764284"
------=_Part_1116_518999958.1711641764284
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
URL=
Pattern
(Ryan:) I have through around this a bit and I have been thinking of someth=
ing even simpler. Just proxying requests with a specific URL pattern (say /=
api/providerregistry/*) and sending them to a specific configured domain se=
rvice (so in this example the provider registry). So basically just acting as a proxy to the domain servi=
ces.
More advanced options
(Carl:) While URL pattern matching would certainly work for me, and while&n=
bsp;I don't have any particular preference, I do think it is worthwhile to =
look at existing standards for making all these services known and to keep =
the software components as "pluggable" as possible.
I know WSDL has a bit extra overhead, but it may be worthwhile as considera=
tion. Perhaps it's time for a spreadsheet to compare the pros/cons of=
different options e.g:
- URL pattern matching
- WSDL 1.1
- WSDL 2.0
- WADL
- any others?
against something like:
- existing libraries (Java, Python, PHP, e=
tc)
- related security models/access control m=
echanisms
- supported "transport" mechanisms
- proxy/pass-through
- support for REST verbs
- compatibility with proposed inter-operab=
iltiy layer architecture
- compatibility with other IHE profiles
- etc.
------=_Part_1116_518999958.1711641764284--