On 01/27/2016 03:31 PM, Dean Troyer wrote:
On Wed, Jan 27, 2016 at 1:47 PM, michael mccune <m...@redhat.com <mailto:m...@redhat.com>> wrote:i am not convinced that we would ever need to have a standard on how these names are chosen for the header values, or if we would even need to have header names that could be deduced. for me, it would be much better for the projects use an identifier that makes sense to them, *and* for each project to have good api documentation. I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them to wade through, the API-WG is making great gains in herding those particular cats, I would hate to see giving back some of that here. so, instead of using examples where we have header names like "OpenStack-Some-[SERVICE_TYPE]-Header", maybe we should suggest "OpenStack-Some-[SERVICE_TYPE or PROJECT_NAME]-Header" as our guideline. I think the listed reviews have it right, only referencing service type. We have attempted to reduce the visible surface area of project names in a LOT of areas, I do not think this is one that needs to be an exception to that.
+1, I prefer service type over project name. Among other benefits, it leaves room for multiple implementations without being totally baffling to consumers.
Projects will do what they are going to do, sometimes in spite of guidelines. This does not mean that the guidelines need to bend to match that practice when it is at odds with larger concerns. In this case, the use of service type as the primary identifier for endpoints and API services is well established, and is how the service catalog has and will always work. dt
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
