You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2021/06/01 18:13:03 UTC

[GitHub] [trafficcontrol] jhg03a commented on pull request #4819: Tags blueprint

jhg03a commented on pull request #4819:
URL: https://github.com/apache/trafficcontrol/pull/4819#issuecomment-852341189


   > Clients would have to preserve all "unknown" fields within the `extensions` JSON, which would make the Go client experience a little tricky, but the Go client's existing behavior of basically dropping all unknown fields when it unmarshals JSON responses is one of the big reasons why we need to follow Semantic Versioning in the first place.
   
   That's not unique to Go.  Any client implementation has these same problems, they just may have better tools to adapt.
   
   I'll also just throw out that this is one of the reasons I'm a fan of GraphQL over REST.  These rigid all-inclusive objects aren't a problem with GraphQL because as a client you request only what you want and not the entire thing.  If 30 arbitrary fields are added to an object, it doesn't change any of my one-way requests, and I'm aware of them at runtime whenever the published graphql schema is updated.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org