[Koha-bugs] [Bug 30818] REST API: Why does a wrong column name still cause a general 500 while validating exhaustively?

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30818

--- Comment #3 from Tomás Cohen Arazi <tomascohen at gmail.com> ---
(In reply to Marcel de Rooy from comment #2)
> The REST API is a great thing. But I must admit that going thru all these
> modules, plugins, etc. the exact meaning of a lot of subroutines is unclear
> and the comments are sparse. Hoping that not only Tomas has a global
> detailed view of what is going on here.. ;)

There are two main things that need to be considered when thinking about the
API tooling:

1. We need to map attributes from the API to the actual DB names. This happens
when creating/updating resources, as well as querying. The latter is the most
complex in the code (i.e. the recursive _parse_dbic_query)

2. When we are using q= in conjunction with x-koha-embed, we need to
prefetch/join the right tables. This is mainly handled by _parse_prefetch.

About (1). In the original implementations, the controllers had two methods:
to_model and to_api. So the mappings were entirely handled there. The problem
with that is the fact we wanted to do more complex things like embedding
related objects, so the API representation of an object needed to be handled on
the object itself. There's some redundancy, most probably in the
attributes_from_api and friends stuff on the Koha::Object(s) method. That could
be polished. But the main thing is it needs to be handled at that level and
reused as much as possible. There are not many more things to optimize there
IMHO.

About (2). This is the difficult part. Embeds can happen at an arbitrary depth.
Like in 'x-koha-embed: biblio.items.checkouts.patron'. As the 'how I should be
rendered on the API' question is answered at the Koha::Object level, we build a
data structure ('embed' param for to_api) that contains a (probably
enhanceable) data structure representing the 'rest of the tree' that each
object needs to embed. Along with this data structure, there's the need to
build the prefetches/joins so we optimize things. Embedding can happen on real
'relations' (thus actual prefetches take place) or just on 'methods output' in
which case no prefetch takes place. This is handled by _parse_prefetch, which
is also recursive.

Regarding to_api(), we are adding new parameters that are passed through to
related objects like 'public'. So each object, needs to know how it should
render on an unprivileged context.

So, TL;DR

Our helper methods take care of handling what the OpenAPI plugin generates out
of the requests, and convert it into:
- Queries, objects, etc with mapped attribute names
- Prefetches are appended to resultsets with embeds
- Generate data structure to be passed to to_api()

And most of the magic takes place in Koha::Object->to_api(). The most complex
bit is querying.

Regarding this bug, I believe the solution is to catch the
DBIx::Class::Exception in the objects.search helper, and return a 400 with a
meaningful message.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.