Suggestions endpoint RFC

This RFC should be the basis for making the suggestions endpoint follow the guidelines.
Bug report has already been filed 
== Actions and routes ==
The following table presents the current implementation, and the proposed changes.
Description 	Action	Proposed path
List suggestions 	GET 	/suggestions
Add a suggestion 	POST 	/suggestions
Get a suggestion 	GET 	/suggestions/{suggestion_id}
Overwrite a suggestion	PUT 	/suggestions/{suggestion_id}
Delete a suggestion 	DELETE	/suggestions/{suggestion_id}
== suggestion object definition ==
DB schema 	Liliputech 	Katrin 	tcohen 	ashimema
suggestionid 	suggestion_id 	 	 	
suggestedby 	suggested_by 	suggesting_user_id 	suggestor_id	
suggesteddate 	suggestion_date 	 	 	
managedby 	managed_by 	managing_user_id 	manager_id 	
manageddate 	managed_date 	 	 	
accepteddate 	accepted_date 	accepting_user_id 	acceptor_id 	
rejectedby 	rejected_by 	 	rejector_id 	
rejectiondate 	rejected_date 	 	 	
STATUS 	status 	 	 	
note 	note 	notes 	notes 	
author 	author 	 	 	
title 	title 	 	 	
copyrightdate 	copyright_date 	publication_year (hide internal inconsistency)	 	
publishercode 	publisher_code 	publisher (see biblioitems) 	 	
date 	date_created 	creation_date 	 	updated_on
volumedesc 	volume_desc 	volume 	 	
publicationyear	publication_year 	publication_year (see above and comment below)	 	
place 	publication_place	 	 	
isbn 	isbn 	 	 	
biblionumber 	biblio_id 	 	 	
reason 	reason 	library_reply 	 	
patronreason 	patron_reason 	 	 	
budgetid 	budget_id 	fund_id 	 	
branchcode 	library_id 	 	 	
collectiontitle	collection_title 	series 	 	
itemtype 	item_type 	 	 	
quantity 	quantity 	 	 	
currency 	currency 	 	 	
price 	item_price 	list_price 	 	
total 	total_price 	 	 	
== Comments ==
--Kfischer 01:52, 30 July 2019 (EDT)
* You have suggestion_date but rejected_date as a little inconsistency. 
* Instead of date_created, use creation_date? (see holds, items ,and other endpoints for comparison)
* Instead of item_price, maybe we should use just price or 'unit_price'?
* I am not sure about the term collection_title - it appears in the GUI too in some spots too and has caused some confusion in translation. I wonder if this should be series instead, which we use in other places.
* Are we sure copyrightdate and publicationyear are both used in Koha in this table? (I know they are in biblio/biblioitems, but not sure for suggestions)
* publisher_code doesn't really fit what we put in there, I'd prefer publisher (see )
--tcohen 9 January 2020 (EDT)
* publisher_code should be mapped into publisher, see the biblios endpoint.
--Kfischer 17:55, 12 January 2020 (EST)
When you look at someting again, new things come up:
Category:RFCs
* suggested_by, managed_by, rejected_by all will all contain 'patron_ids'. I think it would be good to indicate this in the name somehow by using _id. Maybe: suggestor_id, rejector_id, manager_id OR suggesting_user_id, rejecting_user_id, managing_user_id?
* reason = library_reply? Just an idea, as there is always a bit of confusion between patron_reason and reason.
* Still think we need to resolve publication_year/copyrightdate. I think this comes form the different mappings in UNIMARC/MARC21 - but should we make this inconsistency visible to the outside world? Why not just have publication_year and fill in whatever is mapped in the installation in question.