1行で
- 「特定の場合でバージョニングしなくても対応できることはある」程度なので、「バージョニング不要」とは言わないほうがよい
どういうことか
- RESTful API から GraphQL へ、GraphQL から別の Web API systemへ、ということを考えると大きな意味でのバージョニングは必要
- 細かなレベルのバージョニング、たとえば1画面の仕様が微妙に変わるたびに
/foo,/foo_201807_1,foo_201807_2みたいにどんどん特定画面専用APIを定義していく、みたいな意味でのバージョニングは不要 - fieldの追加は無造作に行ってよい
- RESTful APIでもfieldの追加は普通はできる、ただし負荷に注意
- 重いcomputed fieldの場合でも、GraphQLのほうは無造作に追加できる
- fieldのrename, deleteはGraphQLでも気軽には行えない
@deprecateddirectiveはあるが、何かを保証するものではないので削除の際は利用者との間でコンセンサスをとる
