Continuing the discussion from Extension of development deadline:
Today this continues and concludes with the intermediary delivery of a work in progress to demonstrate the integration of authenticated CRUD.
It is based on the milestones M1 and M2 from the collaboration agreement.
What becomes apparent when looking at this, is the missing issue definitions for Anonymous View / Create and Authentication alike. This made the authorization question primary target for implementation of M1 and M2.
After reviewing the high-level concepts in the documentation, understanding the basic components of a Rails application, depicting the 18 primary models used, and testing of the MVC CRUD patterns, different forms of specification of intent where found througout the source code. This renders the implementation strategy from following a linear-hierarchic, top-down model, as such implementing feature branches against specific issues, into a diagonal-transversal, inside-out model, in which cross-references appear and an ‘ecologic’ style of development emerges.
Parallely we have a specification growing to be more explicit, not only in the written documentation, but also from reviewing, implementing and interacting with the application mechanics.
From the code review, more questions appear to be worth asking:
- How are composed models expected to be handled via the HTTP JSON API?
- How are links to be introduced between the high-level models? Some are provided upon creation through providing a foreign key. How do we add or change links between existing resources?
- How do we expect resources to be addressed? Some resources are defined to be addressable via a UUID, while others aren’t. (pad.degrowth.net/s/incommon-api-addressing) Which is the distinction line that we can draw between both? Do we want to address all publicly accessible resources with UUIDs instead?
Technical details live in the associated merge request, where more in-depth information is present.