Stream: dotnet
Topic: How to use WebApi project
Yunwei Wang (Nov 08 2018 at 17:16):
There is a WebApi project in the fhir-net-api repository. Is this supposed to be used as a template for my own server WebApi? Or is this some classes that I can use?
Also this project is on STU3. Is there plan to upgrade to R4?
Brian Postlethwaite (Nov 08 2018 at 20:14):
At some point yes. I'm likely to. I've this to another repo too.
Brian Postlethwaite (Nov 08 2018 at 20:15):
There is a filesystem server project as an example to demo it.
Yunwei Wang (Nov 08 2018 at 20:42):
@Brian Postlethwaite Which repo has that demo project?
Brian Postlethwaite (Nov 08 2018 at 20:49):
https://github.com/ewoutkramer/fhir-net-api/tree/develop-stu3/src/Hl7.DemoFileSystemFhirServer
Brian Postlethwaite (Mar 19 2019 at 00:45):
Those that were looking at using this project, it's now moved repo's and will be deleted from the core repo soon-ish.
https://github.com/brianpos/fhir-net-web-api
There is support for Owin(net 4.7+) and also AspNetCore with essentially the same model you can use between them - to make porting between the facade's easier in the future.
Brian Postlethwaite (Mar 19 2019 at 00:45):
Yes this is just STU3 for now, but getting the structures right, then planning to update to R4.
Brian Postlethwaite (Mar 19 2019 at 03:44):
While making headers available to the model for processing behind the façade, does anyone have opinions if ALL headers in the request should come through, or should some be filtered?
@Xander H. @Kenneth Myhra
(currently all will come through)
Brian Postlethwaite (Mar 19 2019 at 03:56):
Also, should we remove the x_api_key and x_correlationId from the modelBaseInputs class as they are in the headers collection already (included to leave in there, but maybe filter from the headers collection?)
Kenneth Myhra (Mar 19 2019 at 07:14):
Not seeing any obvious reasons except maybe (local) security reasons to filter out HTTP headers, so I would have let all go through.
I would vote for removing them if they already are in the Headers collection, they seem implementation specific and not something you would want to expose in a framework.
Brian Postlethwaite (Mar 19 2019 at 07:17):
I think you're right about the xapikey, but the correlation header, it does do some specific extra work.
Kenneth Myhra (Mar 19 2019 at 08:22):
Yep, could maybe be nice to have it easily accessible. Btw this led me down a rabbit hole and I ended up here: http://build.fhir.org/http.html#custom. Server could set X-Request-Id on response and if the client assigned an X-Request-Id on the request this should be echoed back in X-Correlation-Id.
Brian Postlethwaite (Mar 19 2019 at 09:09):
That's the stuff. Note that the x requestId isn't the correlation Id, and a good idea to allocate another x-request on the way out. I'll do that too.
Brian Postlethwaite (Mar 19 2019 at 10:23):
I've also pushed a develop-r4 branch in there too (only updated assemblies, haven't updated anything beyond that)
And there is 1 unit test failing - not sure if this is the webapi.aspnetcore project, or the notcore FHIR client
@Christiaan Knaap have you tried to call any system level custom operations with the R4 1.2 notcore fhir client? (against your netcore server)
Christiaan Knaap (Mar 19 2019 at 16:18):
No I haven't
Last updated: Apr 12 2022 at 19:14 UTC
