On Mon, 12 Jan 2015, Gregory Haynes wrote:

Awesome! I was discussing trying to add extensions to RAML[1] so we
could do something like this the other day. Is there any reason you
didnt use an existing modeling language like this?

Glad you like it.

I chose to go with my own model in the YAML for a few different

* I had some pre-existing code[1] that had worked well (but was
  considerably less featureful[2]) so I used that as a starting point.

* I wanted to model HTTP requests and responses _not_ APIs. RAML looks
  pretty interesting but it abstracts at a slightly different level
  for a considerably different purpose. To use it in the context I was
  working towards would require ignoring a lot of the syntax and (as
  far as a superficial read goes) adding a fair bit more.

* I wanted small, simple and clean but [2] came along so now it is
  like most languages: small, simple and clean if you try to make it
  that way, noisy if you let things get out of hand.


[2] What I found while building gabbi was that it could be a useful as
a TDD tool without many features. The constrained feature set would
result in constrained (and thus limited in the good way) APIs because
the limited expressiveness of the tests would limit ambiguity in the

However, existing APIs were not limited from the outset and have a fair
bit of ambiguity so to test them a lot of flexibility is required in
the tests. Already in conversations this evening people are asking for
more features in the evaluation of response bodies in order to be able
to test more flexibily.

Chris Dent tw:@anticdent freenode:cdent

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to