https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43460
--- Comment #35 from Pedro Amorim (ammopt) <[email protected]> --- (In reply to David Cook from comment #34) > I haven't reviewed the code but... wouldn't it have made more sense to make > this XML to JSON conversion opt-in at the controller level? > > Requiring x-koha-raw-payload at the request end... makes no sense to me. > We're making everything bend around the ILL? Shouldn't ILL be the exception > to the rule and not the other way around? Hi David, despite the x- prefix, x-koha-raw-payload isn't an HTTP header. It's an OpenAPI vendor extension the route author sets in the route's spec, the same way x-koha-authorization is. e.g. in a plugin's openapi.json: "post": { "x-mojo-to": "MyPlugin::Controller#ncip", "consumes": ["application/xml"], "produces": ["application/xml"], "x-koha-raw-payload": true, ... } On opt-in vs opt-out: before 37762 Koha core didn't accept generic application/xml payloads (MARCXML has its own content type and isn't affected). The intent was for them to be first-class in the REST API, validated against the same OpenAPI spec as JSON, so controllers don't need to care which format came in. For that to hold for every route without extra setup, the conversion is the default. We're not making everything bend around ILL, we're setting a standard which ISO18626 ILL just happens to be the first consumer of. Routes that want to handle the raw XML themselves (like the NCIP plugin) are the exception, hence the opt-out, at the cost of those plugins needing the flag. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
