On Mon, 2 Feb 2015, Chris Dent wrote:
On Thu, 29 Jan 2015, michael mccune wrote:
in a similar vein, i started to work on marking up the sahara and barbican
code bases to produce swagger. for sahara this was a little easier as flask
makes it simple to query the paths. for barbican i started a
On 02/02/2015 10:26 AM, Chris Dent wrote:
pecan-swagger looks cool but presumably pecan has most of the info
you're putting in the decorators in itself already? So, given an
undecorated pecan app, would it be possible to provide it to a function
and have that function output all the paths?
you
On Thu, 29 Jan 2015, michael mccune wrote:
in a similar vein, i started to work on marking up the sahara and barbican
code bases to produce swagger. for sahara this was a little easier as flask
makes it simple to query the paths. for barbican i started a pecan-swagger[1]
project to aid in mark
On 01/28/2015 12:56 PM, Max Lincoln wrote:
tl;dr: I wanted to be able to see what OpenStack APIs might look like in
Swagger and starting experimenting with Swagger in projects for things
like stubbing services, API test coverage, and code generation. In order
to do that I created wadl2swagger [1]
tl;dr: I wanted to be able to see what OpenStack APIs might look like in
Swagger and starting experimenting with Swagger in projects for things like
stubbing services, API test coverage, and code generation. In order to do
that I created wadl2swagger [1]. I've published copies [2] of what the
conve
On Jan 18, 2015, at 9:25 PM, Jay Pipes wrote:
> On 01/13/2015 07:41 AM, Sean Dague wrote:
>> On 01/09/2015 04:17 PM, Everett Toews wrote:
>>> One thing that has come up in the past couple of API WG meetings
>>> [1] is just how useful a proper API definition would be for the
>>> OpenStack projects
On 01/13/2015 07:41 AM, Sean Dague wrote:
On 01/09/2015 04:17 PM, Everett Toews wrote:
One thing that has come up in the past couple of API WG meetings
[1] is just how useful a proper API definition would be for the
OpenStack projects.
By API definition I mean a format like Swagger, RAML, API
B
On 1/13/15, 04:16, "Chris Dent" wrote:
>On Tue, 13 Jan 2015, Ian Cordasco wrote:
>
>> On 1/12/15, 17:21, "Chris Dent" wrote:
>>
>>> On Mon, 12 Jan 2015, Ian Cordasco wrote:
>>>
This worked extremely well in my experience and helped improve
development
time for new endpoints and
On 01/09/2015 04:17 PM, Everett Toews wrote:
> One thing that has come up in the past couple of API WG meetings [1] is just
> how useful a proper API definition would be for the OpenStack projects.
>
> By API definition I mean a format like Swagger, RAML, API Blueprint, etc.
> These formats are
On Tue, 13 Jan 2015, Ian Cordasco wrote:
On 1/12/15, 17:21, "Chris Dent" wrote:
On Mon, 12 Jan 2015, Ian Cordasco wrote:
This worked extremely well in my experience and helped improve
development
time for new endpoints and new endpoint versions. The documentation was
also heavily used for t
On 1/12/15, 17:21, "Chris Dent" wrote:
>On Mon, 12 Jan 2015, Ian Cordasco wrote:
>
>> This worked extremely well in my experience and helped improve
>>development
>> time for new endpoints and new endpoint versions. The documentation was
>> also heavily used for the multiple internal clients for
On Mon, 12 Jan 2015, Ian Cordasco wrote:
This worked extremely well in my experience and helped improve development
time for new endpoints and new endpoint versions. The documentation was
also heavily used for the multiple internal clients for that API.
This idea of definition formats seems li
On 1/9/15, 15:17, "Everett Toews" wrote:
>One thing that has come up in the past couple of API WG meetings [1] is
>just how useful a proper API definition would be for the OpenStack
>projects.
>
>By API definition I mean a format like Swagger, RAML, API Blueprint, etc.
>These formats are a machin
13 matches
Mail list logo
