Hi there, I'm the founder of a company called Stoplight, and we have a purpose built solution for this very use case. You can read more about it here: https://stoplight.io/platform/scenarios.
Basically, you setup test cases for your API(s), and we automatically contract test the inputs/outputs of the requests against your OAS specification where possible. If anything does not validate against the schemas defined in your OAS specification, the test will fail with descriptive errors. If your OAS is ever updated, those changes will automatically work in the tests, since the tests are just referencing the OAS spec (not duplicating data from it).
A couple more things:
- You can create these tests with our visual UI, or write the underlying JSON that describes the tests by hand.
- You can run the tests inside of our UI, or install Prism (our command line runner) to run them completely outside of Stoplight (CI, terminal, etc).
- We plan to support OAS3 later in Q4 of this year.
We live and breathe API tooling and specifications. If you have any questions about process, our product, API strategy, etc, happy to chat - just shoot me an email at marc [at] stoplight.io!
Hi HN, we originally developed this for internal use over at StopLight, and realized that a lot of the tech could be re-purposed and re-packaged into a nice little complementary tool for anybody working with Swagger. Thanks for taking a look - happy to answer questions, and eager to hear any feedback!
Really great feedback, thanks! We've heard that the main navigation is confusing, and are working on improving it as I type this. Could you send me an email marc @ stoplight.io? I would love to bounce some of our ideas off of you, and hear what you think.
Interesting, query params should be published - could you send me the link to the docs you published?
In the "settings" tab for each endpoint, you can mark which security schemes apply to the endpoint. It's kind of hidden, we're moving it to the general definition tab. Also, that info will be exposed in api-docs (which security schemes an endpoint requires/supports) in an update later this week!
Astute catch! We're actually tracking this issue internally already. We'll be beefing up that generator to aggregate multiple values for the same property, when it's an array of objects. Look for that in an update in the next 2 weeks.
Great question! We are considering adding first class support for Blueprint. In the meantime, we recommend converting first to OAI/Swagger with the awesome tool over at https://apitransformer.com
You can invite team members to your workspace in the API Designer, and only they will have access (read or read/write) to the APIs in that workspace.
From the API Designer (which is private), you can optionally publish any of your API versions out to api-docs.io, for public consumption. You don't even need to publish your entire API definition out - you can mark which endpoints/models are private versus public. Only the parts of your internal docs marked as public will be published out :).
It really is free, for individual use, forever :). Pricing starts at the team level - at $8/month/member. We're also introducing cheaper, annual pricing soon.
The hosted documentation integration is completely free - we have a paid option coming soon, that adds custom domains, theming, analytics, etc.
Hey! Marc MacLeod here - founder. Basically, you put Prism between your API consumer (mobile app, website, integration tests, library, curl request, whatever) and the API itself.
Prism processes the traffic that passes through it, and generates your spec code from that. It can identify dynamic parameters in the url, build json schemas, etc.
I believe the idiomatic way to use this library is to treat the tree as an immutable structure. When used this way, it supports the React Immutability Helpers, and the PureRenderMixin. If you treat it as immutable and use the PureRenderMixin, you won't run into the re-render multiple times issue described above.
Ah I did not realize that it's not on EBS (aws announced SSD EBS last June so I thought perhaps you guys jumped on that opportunity). What's the max # of connections? Does it scale with storage as well?
First of all, this is great news - I use compose for Mongo and have been waiting for a PostgreSQL option. However, is the ram allotment similar to that given in the Mongo deployments - 1/10th storage? So, about $125/month for 1GB ram and 10GB storage. Making the obvious comparison to Heroku (which, granted, doesn't offer the autoscaling feature), Compose looks quite expensive. At a glance, it seems that on Heroku one gets the same amount of ram and 6 times the storage for less than half the cost of Compose.
I've built several apps with Meteor, and so far it's been fantastic. Development is lightning fast, the interface is snappy enough, and it's easy to maintain. My latest Meteor app is online at http://stoplight.io.
It does accept multiple emails per day, however it doesn't distinguish within a day. If you send it more than one email per day it will append the text of the email to the existing entry for that day.
Perhaps you could create an account with your work email, and one with your personal email? I hope I understood you correctly!
You can choose which days of the week, and at what time each day, the service send you reminder emails. As for photos, that's next on the list of features!
Basically, you setup test cases for your API(s), and we automatically contract test the inputs/outputs of the requests against your OAS specification where possible. If anything does not validate against the schemas defined in your OAS specification, the test will fail with descriptive errors. If your OAS is ever updated, those changes will automatically work in the tests, since the tests are just referencing the OAS spec (not duplicating data from it).
A couple more things:
- You can create these tests with our visual UI, or write the underlying JSON that describes the tests by hand.
- You can run the tests inside of our UI, or install Prism (our command line runner) to run them completely outside of Stoplight (CI, terminal, etc).
- We plan to support OAS3 later in Q4 of this year.
We live and breathe API tooling and specifications. If you have any questions about process, our product, API strategy, etc, happy to chat - just shoot me an email at marc [at] stoplight.io!