<div dir="ltr"><div>For the moment Manila project, as well as Cinder, does have inconsistency between entity and API naming, such as:</div><div>- "share type" ("volume type" in Cinder) entity has "/types/{id}" URL</div><div>- "share snapshot" ("volume snapshot" in Cinder) entity has "/snapshots/{id}" URL</div><div><br></div><div>BUT, Manila has other Manila-specific APIs as following:</div><div><br></div><div>- "share network" entity and "/share-networks/{id}" API</div><div>- "share server" entity and "/share-servers/{id}" API<br></div><div><br></div><div>And with implementation of new features [1] it becomes a problem, because we start having</div><div>"types" and "snapshots" for different things (share and share groups, share types and share group types).</div><div><br></div><div>So, here is first open question:</div><div><br></div><div>What is our convention in naming APIs according to entity names?</div><div><br></div><div>- Should APIs contain full name or it may be shortened?</div><div>- Should we restrict it to some of the variants (full or shortened) or allow some API follow one approach and some follow other approach, consider it as "don't care"? Where "don't care" case is current approach, de facto.</div><div><br></div><div>Then, we have second question here:</div><div><br></div><div>- Should we use only "dash" ( - ) symbols in API names or "underscore" ( _ ) is allowed?</div><div>- Should we allow both variants at once for each API?</div><div>- Should we allow APIs use any of variants and have zoo with various approaches?</div><div><br></div><div>In Manila project, mostly "dash" is used, except one API - "share_instances".<br><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/315730/">https://review.openstack.org/#/c/315730/</a></div><div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Kind Regards<br>Valeriy Ponomaryov<br><a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a><br></div></div>
</div></div></div>