Revise how entries and feeds are updated

[jfroelich]

• implement patch-entry
• implement put-entry (revised from update-entry)
• implement patch-feed (revised partially from update-feed)
• implement put-feed (revised partially from update-feed)
• change set-entry-read-state to delegate to patch-entry instead of implementing the same logic again
• change activate-feed to delegate to patch-feed
• change deactivate-feed to delegate to patch-feed
• merge activate-feed and deactivate-feed into set-feed-active-state

Eventually:

• consider just patch-resource and put-resource, and merging all of per-feed or per-entry things into the generic resource-oriented operation

[jfroelich]

Interesting article on the concept of patch: https://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

This ties into the idea of emulating a REST API for storage by introducing an intermediate layer.

[jfroelich]

Followup: consider dropping create-entry and create-feed and instead just reusing put-entry and put-feed in each case

[jfroelich]

Random thought: the rest api will provide a strict barrier between objects within the database layer and the objects outside of it in the calling context. in some sense the objects Entry and Feed should actually only be available within the rest api code, and the calling context should just get data objects.

Also, we can completely mask away the magic prop stuff to the user of the rest api. the magic prop would only matter from within the scope of the database layer. outside it is just data object that may or may not have property, and inside, we can auto-insert the appropriate magic. this will change the contract of the database api helpers that read/write data, they become only concerned with accepting data objects and returning data objects. e.g. a write function called by the caller would supply an object without magic, then internally the magic will be inserted before storage. then the read function will grab something from db, assert against magic, then strip magic and return to caller. basically magic only helps type restrictions inside of the rest api, not outside of it. outside of it, entries and feeds are just generic objects that the caller can do whatever with. This ties into that other issue of making magic fully opaque. it would also mean that no caller outside of the database layer should directly use Entry, Feed, is_entry, or is_feed.

[jfroelich]

Other and/or remaining todos:

• deprecate activate-feed
• deprecate deactivate-feed
• change refresh-feed-icons to use patch instead of put
• look into deprecating create-feed/entry and just using put, or look into the rest semantics that represent resource creation

[jfroelich]

regarding previous comment on create semantics, this is the CRUD to REST map:

• get - read
• create - post
• update - put (or patch for partial)
• delete - delete

[jfroelich]

I actually liked the simplicity of this description of REST: https://restfulapi.net/resource-naming/ because it went straight at some the questions I was trying to answer, and pretty much confirmed my thinking.

I think this issue is now mostly resolved.

Things to think about in the future, as separate issues:

• a REST layer above the db layer
• as a part of switching to rest layer, moving to a data-only api, where everything outside of the rest api is just data passed in and out, and everything inside of the api is kind of like now. this is kind o the strong boundary concept i want from a service oriented architecture
• switching to resource (instead of feed/entry)

But see this article: https://www.infoq.com/news/2015/02/service-boundaries-healthcare

• Services share contract and schema, not class or type. Other than pure communication between them, services do not share access to resources, including databases, because this might introduce dependencies between them.
• Services own their data. A service has to have both some sort of functionality and some data. If it does not have data, then it is just a function. If all that it does is performing CRUD operations on data, then it is database. A database should not be made a service just to provide basic operations on data through RESTful calls because these introduce supplementary layers that are not needed. SQL is good enough.

Similar issue (regarding my decision to store favicon data in an entirely separate database):

• Dahan does not see any problem for services keeping their data in the same shared database as long as each service has its own schema.

These are thoughts for a separate issue. This issue is now pretty much complete.