ayanova/devdocs/todo.txt

@@ -122,7 +122,7 @@ todo: PLANNING WORKORDER considerations:
 					 determines what's different, only sends an update for each object to it's own route as appropriate
 					 on successful update fixes up the edited copy of that object
 					 on all updates done, the edited copy becomes the virgin copy (or do we need 3 objects at one point in case of fail?)
-					 
+
 				requires second copy of wo for diffing
 				goes over workorder, looks for changes, sends update for each object individually and patches up local from result
 				so if a workorderitempart has changed then it sends only that for update individually
@@ -133,7 +133,7 @@ todo: PLANNING WORKORDER considerations:
 				WorkOrder/{woid}/WorkOrderItems/{woitemid} <- CRUD single woitemid
 				WorkOrder/{woid}/WorkOrderItems/{woitemid}/Labors <- entire labor collection CRUD ops over all collection (also ADD new labor here (POST))
 				WorkOrder/{woid}/WorkOrderItems/{woitemid}/Labors/{laborid} <- Crud on individual item
-
+https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design#define-operations-in-terms-of-http-methods
 				This way is pretty solid, will result in a lot of routes but a lot of the code can be shared in the biz object, so for example if updating a labor or a collection of labor most code the same
 				Efficiency:
 					Since there is a route for every bit of the workorder the client can pick how high up to update based on diff check