michaelneale · October 2, 2025 03:15
diff --git a/gistfile1.txt b/gistfile1.txt
 Having implemented a swift client to goosed (and others), some feedback on it as a general api: 

 Improvements:  
 * making it easy to start a blank session with config "as is" on disk: ie provider, and extensions, should be one shot (vs now which is many calls)
 * goose-server/ui/desktop/openapi.json can be removed, not sure why it is there. It may also be possible to get rid of the ui/desktop/openapi.json and just generate it on the fly, not commit?
 * we use a simple api key approach, might be nicer to specify a non shared secret approach with PKI (but still easy to implement from client side)
 
 Tidy ups/Questions: 
 * extensions are listed in /config, but enabled in /extensions/add endpoint, which seems kind of inconstent
 * you can add/remove to /extensions, but not clearly documented if you can (and what it means) to add a non enabled extension. 
    - what is add/remove vs enable/not enable, how do you save changes (add? or just )
    - there is /config/extensions which you can post to to add - seems inconstent or confusing?
 * schedule has a lot of service which seems out of proporition with the feature (how much is it used?) - is powerful though, and kind of restful (more so than others)
 * recipes have different less RESTful pattern to schedule (not clear what methods do from looking at them)

 Comments: 
 * /config endpoint looks brittle, very coupled to what is being loaded/saved in config
 * there is a openrouter and tetrate special case route handler, this is ok, but won't be part of some portable/generic spec as just for signups 
 * http still very helpful as transport
	Having implemented a swift client to goosed (and others), some feedback on it as a general api:

	Improvements:
	* making it easy to start a blank session with config "as is" on disk: ie provider, and extensions, should be one shot (vs now which is many calls)
	* goose-server/ui/desktop/openapi.json can be removed, not sure why it is there. It may also be possible to get rid of the ui/desktop/openapi.json and just generate it on the fly, not commit?
	* we use a simple api key approach, might be nicer to specify a non shared secret approach with PKI (but still easy to implement from client side)

	Tidy ups/Questions:
	* extensions are listed in /config, but enabled in /extensions/add endpoint, which seems kind of inconstent
	* you can add/remove to /extensions, but not clearly documented if you can (and what it means) to add a non enabled extension.
	- what is add/remove vs enable/not enable, how do you save changes (add? or just )
	- there is /config/extensions which you can post to to add - seems inconstent or confusing?
	* schedule has a lot of service which seems out of proporition with the feature (how much is it used?) - is powerful though, and kind of restful (more so than others)
	* recipes have different less RESTful pattern to schedule (not clear what methods do from looking at them)

	Comments:
	* /config endpoint looks brittle, very coupled to what is being loaded/saved in config
	* there is a openrouter and tetrate special case route handler, this is ok, but won't be part of some portable/generic spec as just for signups
	* http still very helpful as transport