buildingsmart / opencde-api

OpenCDE API standards

The openCDE initiative is a portfolio of API standards.

The foundation API can be found here: https://github.com/buildingSMART/foundation-API

On top of the Foundation API there are feature based additions:

• BIM Collaboration Format (BCF) API: https://github.com/buildingSMART/bcf-API
• Documents API: https://github.com/buildingSMART/documents-API
• Dictionary API (also implemented by the buildingSMART Data Dictionary): https://app.swaggerhub.com/apis/buildingSMART/Dictionaries/v1 More API projects will follow later.

Please see the buildingSMART Technical roadmap for further reference: https://www.buildingsmart.org/about/technical-roadmap/

opencde-api's Issues

File handling approach is not "open"

Hi,

We are currently reviewing the openCDE-API spec to implement a client that interacts with multiple CDEs. Our client has no support for a UI which means that interacting with OpenCDE compliant APIs is not possible due to the current spec dependency on clients to support a UI e.g for selecting a document.

We think a pure HTTP request/response approach should be considered for development of the API. It would be great to hear thoughts on this.

Swagger file has validation errors

SUMMARY
Swagger file has parse errors

ISSUE TYPE
Bug Report

STEPS TO REPRODUCE
Running the openapi.yaml file through Swagger validation (online, use https://editor.swagger.io/) fails with the following errors:

Initially, it could not render the file because of an invalid version field. This can be fixed by changing line 1 to openapi: "3.0.0"

Further Errors:
Line 4 Structural error at info.version should be string
Line 24 Structural error at paths./cde/0.1/documents/select-documents.get.parameters.0.schema.oneOf.0
should be object
Line 25: Structural error at paths./cde/0.1/documents/select-documents.get.parameters.0.schema.oneOf.1
should be object

Support for re-reading files

The API does allow user to choose a file via a web browser basically and then the application to read the contents of that file.

But does this API support the application to keep a unique identifier of that file, and later use that identifier to query the status/version of it from the server? The application would then see if the version has changed indicating changes in it and re-read the contents of the file. This would allow the application to automatically update the local contents from a server file.

Foundations spec is missing an authorization section

The authorization section in the BCF API 2.1 specification, which was used as the baseline for the foundations API spec is too BCF specific and I decided to remove it. The group should discuss whether/how the foundations API would specify guidelines around authorization.

This discussion is closely related to project services which have been excluded from the foundations API for now.

WebDAV as Documents API contract?

Forgive if this is a silly question - trying to get up to speed on the latest work here: Has the team considered use of an existing neutral file management API like WebDAV for the Document API? WebDAV gives most of what you'd expect to find in a file API (files, directories, movement commands, locking, etc). Extensions like Delta-V support revision control too. Is there too much of an impedance mismatch between WebDAV and existing industry file systems? Too much overhead to implement the full protocol?