Subscribe
Sign in
Stoplight.io — Supercharge your API strategy
14
Replies
Best
darrin
Exciting product guys - congratulations!
I love how you've pulled everything together and we finally have someone tackling the full lifecycle of API development and design in earnest. One question - do you or are you planning on tackling the somewhat sticky issue of API versioning?
Report
Share
@darrin We have support for simple versioning, and we just added support for environments(it is in beta right now). Is there anything in particular you were looking for with versioning?
@tom_pytleski Sorry that was a bit vague - let me elaborate a little - because I think you probably can help in this area if you're not already!
When people first think of creation and design of APIs it's often in a green-field environment. Many don't think about what happens after the API is being used. Successful APIs (the ones you really want to keep around) inevitably need to evolve over time. The designer needs to think - how do you make sure you don't break people as you evolve to provide new functionality on existing services? Certainly micro-services help but there's more to it. How do you communicate in your docs when things are/were introduced and when they are deprecated? Planning for this in advance helps a LOT. One could adopt a policy e.g. of creating a clone of all resources in a 'v2' branch for example at least for breaking changes - which I don't love but it's not a totally unreasonable policy.
It sounds like environments might help in this area - or this might end up just being a simple recommendation (e.g. a blog post) on how to use stoplight.io so that your customers can successfully evolve their APIs over time... and of course Stoplight is there helping over that entire journey.
Hopefully that helps clarify a bit... exciting product guys! Looking forward to using it!
@darrin Environments are more so for using different api keys for example in your local development vs. staging vs. production. They don't have much to do with versioning per say.
We take the duplicate approach right now. Then from there you can clean it up how ever you want. Or you can import your swagger or raml spec.
As far as communicating changes between updates/versions we leave that up to the user. We have a commit system that makes it easier to see what has changed between the last time docs were changed. We also have a tag system so that you can tag things as deprecated, or not supported, ect...
We are working on finishing up scenarios right now atm, and as soon as we are finished with them we are going re evaluate everything and see where we can improve. We have some exciting ideas for design/documentation.
Does that answer your question?
@tom_pytleski Thanks Tom - yeah I think that'll do it. Duplicates plus tags sound like a reasonable approach - thanks for sating my curiosity!
Check out Scenarios hunters! Share what you create here! Adding examples right now! If you already have an account, please log out to see the examples at the link below.
https://app.stoplight.io/scenarios
We're big fans of StopLight at SendGrid and it has greatly improved our API product process across the board, from design to testing to generating docs and libraries. Check it out: https://sendgrid.com/blog/stopli...
Their tools have helped us save years of programming time!
As a bonus, their interface is a pleasure to work with. All that, coupled with amazing support, makes me believe this will be THE suite of API tools.
I wrote about how we use StopLight and Prism at SendGrid here: https://sendgrid.com/blog/stopli...
Thank you for hunting our v2 launch Siddharth - really appreciate it!
For Stoplight, this release marks the culmination of 6 months of work polishing the three main parts of our platform (Modeling, Documentation, and Testing). We are very excited to share this with everybody!
We also have new documentation over at https://help.stoplight.io (yes, we dog-food and that is powered by our own docs product).
We are simultaneously launching the beta of our next generation testing and automation product - Stoplight Scenarios - more info about that (and beta signup) over at https://v2.stoplight.io/platform.... Excited to share more in the coming months.
Here to answer any questions - thanks again Siddharth :).
@prmurphy Scenarios are different from what Runscope does. Runscope is meant for monitoring your API after you have deployed it in the wild. Right now, there is no way to schedule scenarios and run them periodically but that is going to come soon. Scenarios are really nice for debugging and catching bugs while you are developing your apis. You could replace all your integration tests for your api.
@prmurphy Great question - we are planning to add light scheduling to scenarios, but nothing as comprehensive as Runscope (in the domain of API monitoring). We're actually chatting with the Runscope guys about a possible Scenario -> Runscope monitor one click flow.