Allow additional data

Open
#361 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale

Research direction

Start by reviewing the existing files_information endpoint and the proposed /meta routes for projects, topics, files, comments, and documents. Compare the metadata and additional_data examples, then clarify the supported fields, value types, and response behavior. Done means an agreed, implementable specification for standardized additional data.

Written by the indexing model from the issue text.

Description

Every implementation I've seen of the BCF API has additional data in the responses; it's only natural, since every software has features not found in others that they want to handle.

However, I think it's possible to standardize these infos (at least some of them), so that a client could at least display them, and even allow to dynamically generate a form with values. There's already some semblance of this in the files_information endpoint but I think it's not enough.

Here's a quick example.

Define data

Create a /meta route suffix for some routes: projects, topics, files, comments, documents. I feel these are probably the most likely to have non-standardized informations.

  • /bcf/{version}/projects/meta
  • /bcf/{version}/projects/{project_id}/topics/meta
  • /bcf/{version}/projects/{project_id}/topics/{guid}/files/meta
  • /bcf/{version}/projects/{project_id}/topics/{guid}/comments/meta
  • /bcf/{version}/projects/{project_id}/documents/meta

These routes would return the following informations:

[
  {
    "code": "X",
    "label": "Label X",
    "id": "f8fab089-e26a-46d1-8a6c-721e4a8435d8",
    "is_mandatory": false,
    "is_modifiable": true,
    "maximum_length": 200,
    "value_type": "String"
  },
  {
    "code": "Y",
    "label": "Label Y",
    "id": "9e203f1b-7881-4cda-8dac-acc706184595",
    "is_mandatory": false,
    "ismodifiable": true,
    "maximum_length": 10,
    "value_type": "List",
    "values": [
      {
        "code": "A",
        "label": "Label A"
      },
      {
        "code": "B",
        "label": "Label B"
      }
    ]
  }
]

Display data

The data defined in the /meta endpoint would be returned in the following way, for instance for a project list /bcf/{version}/projects/:

[{
    "project_id": "F445F4F2-4D02-4B2A-B612-5E456BEF9137",
    "name": "Example project 1",
    "additional_data": [
        { "code": "X", "value": "Lorem ispum" },
        { "code": "Y", "value": "A" }
    ]
}, {
    "project_id": "A233FBB2-3A3B-EFF4-C123-DE22ABC8414",
    "name": "Example project 2",
    "additional_data": [
        { "code": "X", "value": "Donec tortor nisi" },
        { "code": "Y", "value": "B" }
    ]
}]
Dominant language
No language data
Stars
238
Forks
67
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from buildingSMART/BCF-API

All issues in buildingSMART/BCF-API

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.