support synapse ID with dot notation for versions

Description

introduced this for wikis. It would be extremely useful for the clients as well. Now, if I have an entity that I need to get a specific version of, I need to do:

May be fine for one entity, but I have apps/tools that are getting 10s of entities, which doubles the amount of things I need to enter to do this.

Environment

None

Activity

Show:
Kimyen Truong
May 10, 2019, 5:36 PM

My thoughts:

  • If we support this in the client by adding logic to the client to split “syn123.4” into entityId “syn123” version 4, there are many things to consider:

    • Do we support “123.4”? without the “syn” prefix?

    • There is an implementation in the R and the Python client that tell users how Synapse behave. This implementation is separated from the Synapse backend. The backend change happens much faster than the client change because of different release cycles, and how SaaS and desktop application are used. When the backend changes its behavior, it either:

      • Blocked by the client implementation.

      • Become inconsistent with the client.

  • If we support this at the service level, for example, allowing GET /entity/{entityId} to accept “syn123.4” as a valid entityID, the backend and the client is now consistent. The client should not have special logics to handle features/ behaviors that is supported by the backend server.

  • I have been looking into how others build Python client for RESTful services. Most packages that I found, including boto3, was developed by simply wrapping the REST services without adding any special logics. It only support object types and functionalities that the services support. This brings many advantages:

    • The client can be very simple python wrapper around RESTful services. Developing the client can be as simple as defining the “objects” and “actions” that we support. Code can be written to automatically generate the Python functions.

    • Consistent behaviors across the services and the clients.

 

Assignee

Unassigned

Reporter

Kenneth Daily

Labels

None

Validator

Kenneth Daily

Development Area

None

Release Version History

None

Slack Channel

None

Components

Priority

Major