Phil Sturgeon, Transforming APIs @ WeWork
Phil Sturgeon is a Platform Engineer @ WeWork . He loves talking about APIs and working with them. He is a big advocate for API Specifications and is an extensive user of APIMatic’s Transformer. We got an opportunity to talk to him and made the most out of it. Read on to find out more about our discussion.
- Tell us a bit about yourself. What do you do and what’s your job about ?
I’m working at WeWork. Most of my job is shouting at people. *laughs*. I've spent a lot of time working with API Specifications. Trying to open a whole bunch of things along the lines of API specs, SDK generation etc. So basically, all the stuff that you do, I’m trying to make it happen at WeWork. Just recently, people came up with the idea that we could on board our engineers with API documentation.
2. How long have you been working in the API space? And how did you decide to get into this space ? And what are you working on currently ?
It happened fairly naturally. I think for almost 10 years now, I’ve been working with APIs. It just seems that most of back-end development has moved away from admin panels, CRUD, and stuff like that. Like let’s build a hotel booking system that can handle this. But we've moved from that now. I spend less time creating forms, and more time handling back-end requirements.
Staying in this space is not really a plan, it’s a necessity. Generally, people need APIs and I cannot imagine not working on them. At WeWork, we use APIs to create meetups at WeWork locations. WeWork has access to the Meetup API and Meetup has access to the WeWork API. That’s just how the API world works. There’s roughly like 50 different services in the company. The way it was described to me when I joined the company was… if you wanna start a hotel, you’ll need to install a hotel software. You just buy one of these pre-built packages and shove it in there and it’ll tell you everything like, how many rolls of toilet paper do you need to store on a daily basis. It has every minute detail about everything that you need. There’s nothing like that for co-working spaces.
3. Since you work revolves around API Specifications, can you let us know which one do you prefer and why ?
That’s a great question. OpenAPI and JSON schema are both currently my favorite. The main reason for that is there are only the ones that actually exist in a useful way. There are a lot of specifications around, there have been many over the years, there’s WSDL and people have used that so much, API Blueprint was a big favorite of mine for a long time, it was really simple, it was markdown based, so it was a lot cleaner to write. They had meaningful indentation but the tooling wasn’t very useful, there wasn’t much tooling around, like you wanted to generate documentation there was only Apiary. So I started looking around , I wanted something JSON Schema based, there’s so much you can do with JSON schema, you can do amazing contract testing, a number of validations, JSON schema is really really cool. RAML is also a great format , but they kinda gave up on the API Specification game and started moving towards API Management and really the only option we are left with was OpenAPI specification.
4. What is the basic use case for API Transformer for you ? How does it fit in your work flow ?
We use APIMatic’s Transformer in two different ways, the general work flow is that we ask people to write OpenAPI specifications, but many of us do not want to write out a bunch of specs by hand. Quite often we get Postman Collections, API Blueprints specs, and as we acquire more companies, they bring their own formats, whatever they bring, we have it go through the API Transformer to output OpenAPI Specification. APIMatic’s Transformer allows us the flexibility to improve and upgrade things at a very early stage. Also no other specification converter can handle as many formats.
The other use case for API Transformer is to convert OpenAPI Specs to Postman Collections. With the transformed file, we use Postman Pro API to push these changes to Postman, this really makes documenting our APIs really easy, all we have to do is click “Save Now”, and then that would be it. It’s helps us form an amazing pipeline.
5. We are curious about one more thing. Have you got the chance to checkout other tools and services APIMatic has to offer like SDK Generation or API Documentation ?
My goal so far has been to get teams on board with API Specifications. Anything beyond that is months away. The API Specification world is amazing, there’s so much you can do, documentation is the lowest hanging fruit, there is continuous integration, you can contract test your code, you can make sure your documentation and code are saying the same thing and that there are no inconsistencies. I really want to get to the point where we have automatically generated SDKs and so much more, but first we want to have our bases covered and get done with the lowest hanging fruit i.e. documentation.
6. How do you think can we improve Transformer ? How should we go ahead with the product ?
“ I think you guys are in a really interesting position and are the only solution to a problem that’s very common. People need an API Transformer, they need it to convert from one specification to another. There are loads of tooling around which suck and there’s only yours which works. “
Even though this is a niche area, this is the only one and only solution available, that’s rare, that’s unique and you are lucky to have that. It’s a public service out there for anyone to use, it’ll be a shame if you guys start charging, but only fair, specially with rate limiting and all. That’s how APIs work, you do this much for free and for the rest you pay up. That makes sense.
I think focusing on producing an even better Postman Collection can be very interesting. We have been using OpenAPI to Postman Collection like i mentioned, unfortunately it does not do much with variables there’s a feature i know you have been working on, turning the servers away, people in Postman like to switch away with staging and production and right now output from Transformer does not cover that and i am super excited to see what guys can come up with.
7. How has the support been so far for you ?
“It’s amazing, i have never seen such a quick and positive reaction to bug fixes, every time we have a bug, the support’s like we have fixed it, this one will be done today, that tomorrow, it has always been great you know. “
8. Also with your great insight into the API space , what emerging trends do you see ?
I don’t spend too much time imaging what’s ahead, i am just consistently trying to get people catch up with tooling that’s already been around for 10 years. I do think we are an really interesting point where GRPC and GraphQL have caught up, they are both making people talk about types, i think API Specs are gonna be more popular, people are gonna realize GRPC and GraphQL are not a silver bullet, a lot more REST API developers are gonna care about type and type strictness.
We are really grateful for Phil for taking out the time to talk to us and for offering us his valuable feedback. Also we are really glad he could drive such amazing value from our offering. See what you can do with API Transformer to make your life easy, Sign Up today for free !
