On 02/03/2015 01:49 PM, Everett Toews wrote:
I think where we want to focus our attention is:
* strict adherence to correct HTTP
* proper use of response status codes
* effective (and correct) use of a media types
* some guidance on how to deal with change/versioning
* and _maybe_ a standard for providing actionable error responses
* setting not standards but guidelines for anything else
really solid starting point, the last point deserves emphasis too. i think we should be
very mindful of the idea that these are guidelines not hard standards, but i haven't
heard anyone in the meetings referring to them as standards. it seemed like we had
consensus about the "guidelines" part.
It’s early days in the API WG. Coming up with a list like this at the outset
seems overly restrictive. How does something get on the list? How does
something get off the list? Whatever the answer, I can see it taking a lot of
wheel spinning. I prefer to keep things a bit more open early on and let it
evolve.
that's something i hadn't thought about, the process behind a list of
this sort. i don't mind having this list as a starting point, but i also
agree with Everett for the need to establish an open and transparent
working group. i'm also a big fan of the evolutionary growth model for
this effort.
I’ll echo Mike’s sentiment that we should be very mindful of the idea that
these are guidelines not hard standards. Hmmmm…even that might be a bit
restrictive. In the Openstack HTTP error codes [1] discussion I’m getting the
impression that there is a desire to make this a standard. Perhaps we need to
leave the door open to setting standards in certain cases?
i guess this is a point we should address as well, the possibility for a
long term path towards standards. it's a tough chicken and egg type
situation, especially given the desire for openness and free growth. i'm
not sure how we would best flag that standards may someday evolve out of
the wg, or even if we need to.
mike
__________________________________________________________________________
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
