feat: add JSON API for FDO Owner Server with OpenAPI specification #130
Conversation
djach7
force-pushed
the
owner-api-refactor
branch
2 times, most recently
from
5e7dc09 to
dfb5a39
Compare
Implements comprehensive JSON responses for all FIDO Device Onboard Owner Server endpoints while maintaining backward compatibility with existing PEM-based clients through Accept header content negotiation. ## Key Features - All Owner API endpoints return JSON by default - OpenAPI 3.1 specification ready for code generation - Comprehensive test coverage validating JSON responses - Backward compatibility via Accept: application/x-pem-file - Split server architecture preserved - Consolidated error handling patterns ## New Files - api/openapi/owner-server.yaml: OpenAPI 3.1 specification (139 lines) - api/handlers/responses.go: JSON response utilities (108 lines) - api/handlersTest/json_api_test.go: JSON validation tests (84 lines) - api/handlersTest/helpers_test.go: Test helper functions (26 lines) - api/openapi/README.md: Documentation (25 lines) ## Modified Files - api/handlers/vouchers.go: JSON responses + error consolidation - api/handlers/ownerinfo.go: JSON error handling - api/handlersTest/vouchers_test.go: Updated for JSON expectations - Makefile: Added OpenAPI validation/generation targets - .gitignore: OpenAPI generator artifacts ## Testing All endpoints tested with comprehensive JSON validation: - TestJSONResponsesRequired: validates JSON Content-Type headers - TestInsertVoucherHandler: voucher operations with JSON responses - TestBackwardCompatibilityPEM: ensures PEM clients still work Signed-off-by: djach7 <[email protected]>
djach7
force-pushed
the
owner-api-refactor
branch
from
dfb5a39 to
12406f4
Compare
mmartinv
left a comment
mmartinv
left a comment
There was a problem hiding this comment.
While I think this is a good step forward to having an implementation we need more refinement and agree on the tools we are going to use and how to split the APIs, e.g.: the health api is going to be use by all the servers and we don't need 3 different implementations, the same will happen with the device CA cert management)
| // Handle both raw PEM and form-encoded PEM data | ||
| var pemData []byte | ||
| contentType := r.Header.Get("Content-Type") | ||
| if strings.Contains(contentType, "application/x-www-form-urlencoded") { |
There was a problem hiding this comment.
According to the openapi document the post operation accepts application/x-pem-file only.
Either way, I don't think posting the ownership vouchers embed in a json document adds any value, it makes more difficult to upload the OVs as we need to build a json document now.
| .PHONY: generate-api | ||
| generate-api: validate-openapi | ||
| @echo "Generating Go server and client code from OpenAPI specification..." | ||
| @mkdir -p $(GENERATED_DIR)/server $(GENERATED_DIR)/client | ||
| openapi-generator generate \ | ||
| -i $(OPENAPI_SPEC) \ | ||
| -g go-server \ | ||
| -o $(GENERATED_DIR)/server \ | ||
| --additional-properties=packageName=openapi,outputAsLibrary=true,sourceFolder=src/main/go | ||
| openapi-generator generate \ | ||
| -i $(OPENAPI_SPEC) \ | ||
| -g go \ | ||
| -o $(GENERATED_DIR)/client \ |
There was a problem hiding this comment.
Instead of using a Makefile target to generate the api I would prefer to use the golang native approach to generate code, please see https://github.com/oapi-codegen/oapi-codegen/?tab=readme-ov-file#for-go-124 as an example. We will need a Makefile target anyway but in this case it will run go generate and we will make the build target to depend on it.
This leads me to open the discussion about using the openapi generator tools (java) or the more native oapi-codegen shown in the link above.
After thinking a lot about this I think we should use the native tool as it's very well documented and used by other projects, but as I said this is open to discussion.
2 participants
Implements comprehensive JSON responses for all FIDO Device Onboard Owner
Server endpoints while maintaining backward compatibility with existing
PEM-based clients through Accept header content negotiation.
Key Features
New Files
Modified Files
Testing
All endpoints tested with comprehensive JSON validation: