API (REST) Methods:

	POST 
		201 - Created with Location Url in Header.
		No content
		
	GET
		200 - Abandoning the Response Envelope.  
		Directly returning the result object
		
	PUT
		Return Content only if side effects have changed the object
		data from what was sent in.  (200)
		
		if the updated objected matches what was sent, then respond
		with no content (204) (Use the NoContent return object)
		
		PUT to a resource that doesn't exist -- 
			404 Not Found
			
		
		
	DELETE
		204 No Content (predominantly)
		404 when trying to delete something that doesn't exist.
	

Architecture/Abstraction
	Application API Layer
		Structure naming convention - XyZ
	
	Composition Layer
		Structure naming convention - XyzModel
		rename XYZQueries
	
	Data Layer
		Structure naming convention - XyzDataModel
		XYZDataQueries
		
	Service Layer (Service Adapter Layer)
		Structure naming convention - XyzServiceModel
		XYZServiceQueries

	We *might* want to consider a new Composition solution folder (at same layer as Adapters, WebServices, UX)
		
	Result vs. ServiceModel
		Do we need all those? Aren't they all just models?
		
		A 'Result' is an artifact of an older attempt at returning items back out of API methods.  No significance.
		
		Model	-- Representation of Data - Can be properties and methods
			internal data structures within our projects.  Can pass between projects		
		
		Request and Response -- Specific to externally-facing endpoints
			We'd only expect to see Request and Response objects defined in projects that are either exposed externally
			or that reference external services
		
	Organization - Type-centric or Business Object-centric?
		i.e.:
		Models
			PlanModel
		Factories
			PlanModelFactory
		Services
			PlanService
			--- VS ---
		Plans
			Models
			Factories
			Services
	
		We'll stick with what we've been doing.  Using an architecture-type-centric approach.	

	Interface Constraint Documentation
		We need to document any constraints or 'rules' around the interface and then we have to follow those
		rules when we create implementations.  
		

UX --
	Can delete:
		app/edgilHandlerApp.js
		app/subscriptionmanagementApp.js
		app/app2.js