Swagger is now the OpenAPI Specification
buildazure.com
buildazure.com
But in all seriousness, while I dont believe much in code generation and super smart generic client, a common platform for describing rest apis is more useful than reinventing the wheel for every new service or rather worse - a Word document on Sharepoint with endpoint description.
I personally prefer API Blueprint, but even there is room for improvement.
It’s strange to have been playing this game long enough to see a full cycle.
Here be dragons.
Furthermore, with an http api and depending on your security model, you can test/inspect a good portion of your APIs directly with a browser - a zero-cost client for all http apis that you get for free.
It might be a benefit of statically typed languages though. I have no idea how you would automatically generate swagger from Javascript, without adding so much annotations that they become a poor man's types.
I see it more as an interactive documentation generator than some kind of dynamic API pipe dream.
Rather than attempting to sort it out, I used Paw[2] to get my arms around the API from a consumer's POV, had Paw generate a skeleton of an OpenAPI 2.0 (Swagger 2.0)[3] description, converted it to YAML[4] and began putting flesh on the bones manually (yaml-mode[5] in Emacs is pretty decent). In the process of covering all the bases with precise req/res definitions and examples (yay, JSON Schema![6]), I uncovered a lot of corner cases in the API's functionality and made sure they were handled properly or at least documented well.
I co-located the openapi.yaml file and ReDoc[7] with the API, and now it has beautiful web-based documentation. It also has JS, Python and curl code samples for all endpoints, generated with Paw and included in the YAML formatted description. ReDoc displays them nicely, with syntax highlighting.
In short, even though I worked "backwards" — matching the OpenAPI description to the functionality — it was a fruitful exercise and the results seem pretty good. Not to mention, all the above is readily tracked with git and can live right next to the server's source code... compared to, say, an equivalent documentation effort accomplished with MS Word.
[1] http://www.django-rest-framework.org/
[3] https://github.com/OAI/OpenAPI-Specification/blob/master/ver...
So I worked "backwards" in the sense that I put myself in the perspective of a consumer of the information it serves and then documented the server's behavior with OpenAPI. Certainly, in the process I made much reference to the Python code used to implement the server's endpoints, but some of the endpoints' quirks were discovered in the process of precisely describing (with OpenAPI) their inputs and outputs.
Paste your specification into the editor, fix it if it's not valid, open the "Generate Server" dropdown in the top menu, and select "python-flask".
1. Having strong and documented boundaries at API level
2. Being able to generate clients from a server spec, so I don't have to write interop code anymore.
3. Being able to generate server client from a design document (the spec) - I did it just last week, and it works magically. Should I do it by hand?
Swagger is bad only if you use it wrong, like it's the case with SOAP, Java, and other things which have good parts but have been misused so many times people got pissed of them.
GRPC, for example, is a vast improvement over JSON+REST.
YMMV with Swagger, as I've never tried it.
You define a few data types to communicate about, and call procedures remotely with them. I mean it’s right there in the name!
Unfortunately it doesn’t come with a Methodology you can cram your business or research problem into. It just wants to talk about your problem. Way too on-the-nose for many tastes.
It needs a religion attached, then masses will follow.
I was hoping to not do this 2 years later so really looked hard into it. I was dismayed to find that all of the good looking out of the box tools required writing docs by hand, no generation! I looked back into swagger 2 and found great success this time around. A few things were important:
1. Building the API how I wanted which involved integrating docs into the actual functionality. For instance, all params and response attributes are defined in the code and then turned into documentation later. 2. Spending time to get the docs how we wanted them, not just going with the stock. 3. Not being afraid to break the spec with custom json descriptions when necessary. Not pretty but entirely functional.
We do not use swagger for auto generation or testing, only documentation. I do not think that the current swagger UI implementation is attractive and think they're missing hard by not spending more time on the design style that is trending now. The spec itself is solid.
I'm going to promote the blog post I wrote about it. Feel free to not read it if you're not into self promotion. https://medium.com/salesloft-engineering/building-the-new-sa...
https://www.youtube.com/watch?v=Mhllo1xQer8
in particular 1:45 to 2:00.
Instead of documenting their API, they gave me a WSDL file to download and told me to plug it into any WSDL-supporting SOAP client.
So I threw it into http://fagiani.github.io/savon/ in a Pry session, got back an object representing the API gateway, and then just... started exploring the API using it and Pry, treating the objects and their properties the way I would those of a regular Ruby library.
It was honestly a nice experience, and it would have been even nicer if I had to deal with more than one API, because I could have just kept dealing with Savon rather than finding a new (maybe not-very-well-written) client library for each new service.
So, I don't get the hate for SOAP/WSDL. Is it the process of building the SOAP service that's frustrating? The process of creating the WSDL document? I didn't have to deal with either of these, so maybe that's where the hatred boils up from.
Was it integrating code-generation into the build process? Again, since I was using a dynamic language (Ruby) whose SOAP library (Savon) parsed WSDL and built up its client-proxies in memory at runtime, I didn't have to deal with this.
Or was it dealing with brittleness and edge-cases and a lack of fidelity in the types you could pass through such APIs? I didn't have a problem with this personally, but I might have just been dealing with a uniquely-well-architected backend service.
AFAIK one of the sources of hatred for SOAP is people building the message bodies by hand using browser JS instead of using a code generator (one might not have existed for browser JS at that time). Not only was it complicated by being XML, but SOAP bodies are especially verbose XML.
In a recent project, a client saturated their wire as a result of just this.
This swagger stuff is actually a step backwards, as rest was never meant to be used for api specifications anyway. Or at least the primary focus of it seemed to be hypermedia and evolutionary interfaces.
Neither swagger nor soap are really what I'd expect after 20 years of trying to come up with something though. Would have expected something far more powerful that has more of a functional style, allowing for various combinators and such to be generated.
I'd expand this a bit further too: they tried to make them look like regular function calls in an age where asynchronous/callback programming in general was a nightmare.
At least in C# today, a lot of the debug pain I recall helping other developers through with the old SOAP/WSDL WCF auto-gen code would be solved with async/await. Practically no one understood the Begin{FunctionName}Async/End{FunctionName}Async pattern that the best of those wrappers used at the time and so many developers settled for synchronous blocking and deadlocking anti-patterns instead.
Which again leads to the more general problem with such things that: when they worked right they were magic, and when they didn't work they were (practically) impossible to debug.
There is something to be said that, too, that no one wanted to write a WSDL definition file or a SOAP wrapper by hand, so you were always fighting your tooling to produce what you needed and had a hard time correcting it when it did something sub-optimal.
I don't think swagger is a terribly huge step backwards as in general what I've seen of swagger is lot more descriptive than prescriptive. I've seen some swagger-described APIs that are heavily hypermedia and take a strong REST approach, and I've seen some swagger-described APIs that might as well be SOAP for as much as they resemble "proper" REST and/or hypermedia. It certainly feels more pragmatic than SOAP/WSDL, in trying to describe a lot of the variety in how people build REST-ish APIs, and maybe in that way it's a step forwards from a once-sized-fits-all prescriptive approach. (In that way it too is a step backwards in that sometimes a good prescriptive approach might lead people more easily down a "happy path" of best practices, but that's always the hard balance: pragmatism versus theoretical purity. The pendulum swings.)
In my experiences with SOAP and WSDLs, the code-generated java2wsdl and such wrappers were a way for many vendors to claim "we have an API to support your SOA!" when all they were doing was dynamically generating a WSDL file from a database schema (a lot of service desk and CMDB software like BMC Remedy and Atrium, HP Service Desk, etc. do this) and for a lot of enterprise applications that were basically made to sell a cash cow stack like an ITIL stack with CMDB. So your WSDLs constantly changed because every time someone changed a table's schema you'd need to generate and distribute the WSDL to everyone - this is a guaranteed workflow in an enterprise software situation with dozens of partners comparable to what happens when you get a call from your doctor that you have an STD. This pattern should also sound really familiar to the folks from the mid-90s - it's exactly the hell that began with CORBA objects and other systems that inevitably required everyone to recompile and redeploy their services whenever there was any schema change whatsoever, and unless you had a super-duper effective object AND service registry with accompanying object repositories all provided by some expensive vendor, your class definitions would routinely get desynced and you'd be forced to update your WARs and EARs if you didn't have more expensive hot-loading JVM plus correctly working lifecycle management that wouldn't leak memory (almost none did because of how difficult it was to write decent classloaders that would correctly use ephemeral and weak references for high-concurrency DBs). Thank goodness we had other options with message passing architectures in enterprise (Protocol Buffers, Thrift, etc. all got around the tyranny of class serialization that the distributed object enterprise architect Mafia wanted) but messaging has its own problems from a deployment perspective that made SOAP-based endpoints more attractive then.
This kind of centralized, byzantine, top-down design was the Holy Grail of enterprise application architecture that has ultimately failed in basically every single implementation I've seen or heard of except for the most trivial implementation cases or that required extremely authoritarian, didactic approaches resembling the Crusades or Gallic Wars rather than (now more common) collectivist collaboration toward software development. Either way, innovation slowed to a crawl as internal compliance and standardization become the only output of the software organization or nobody wanted to even try to evolve the system much over time. Open Source is not immune to this kind of bikeshedding culture.
The easier decoupling of services and ability for services to move at their own pace while freeing themselves from the data schema ERD-UML-death-squad-by-committee is what moving from the SOAP ecosystem bought us. The Enterprise Software Apocalypse's Four Horsemen surely included at least the names UDDI, ESB, and SOAP. While I sometimes miss a WSDL to make getting started with an API easier there is no way I miss the typical SOAP service that typically wrapped legacy command line applications older than myself and misrepresented them as something actually scalable or added 25 layers of class hierarchy to express a custom integer or string type for no apparent reason besides a Antediluvian form of input validation that combines the pedantry of Haskell typing with none of the power and elegance. These are not features that deliver business value to anyone besides enterprise software vendors and independent consultants seeking to overcomplicate every software system beyond the comprehension of its own engineers.
TL;DR - I'm afraid that we're starting to regress back to what the J2EE ecosystem tried and failed to do even within monolithic companies because many people never had to design and (more importantly) operate and maintain these centralized, specification-first APIs that have historically hurt innovation and collaboration, not helped.
The enterprise architect mafia just got new toys. :)
I remember playing with the SOAP API of gforge advanced (PHP), and it was not a pleasant experience.
What specially bothered me was how this API tended to return internal IDs instead of resolving them server side and directly give high level and useful information. And there was other issues like returning html escaped text instead of the raw text directly.
It really gave me the impression of an API exposing the raw sql tables.
In the end, I managed to do what I wanted (export the tickets to automatically generate a changelog), but it took me quite a lot of time and a disproportionate amount of code (vs an API like the github one).
I still have the code, but I'm far from proud of how it turned out: https://github.com/kakwa/gforge-soap-client/blob/master/gfor...
And will keep on coming back even after REST gets replaced something else.
Most want a simple network programming model that looks like regular code, even though distributed systems are anything but simple.
Maybe the problem with a lot of RPC tools is that they conflate serialization format and remote call semantics (or "complect" these two factors, if I were inclined to mimic the pretentiousness of Rich Hickey).
Also having integrated against a couple SOAP APIs, it's a bit annoying to write API client tests using recording / mocking of HTTP requests -- since the first thing your client has to do is actually grab the WSDL, your recordings are bloated. (I use VCRpy a lot for this use-case, and it's very convenient for REST APIs.)
Not sure where the best practices are on bundling a copy of the WSDL with your binary; not sure if your app can survive the WSDL spec changing under your feet, but at the same time, if the API changes its spec using a cached version of the WSDL won't work either.
The generated code was a byzantine mess. The bug didn't trigger anything catchable in the code.
This wasn't even the worst thing in that project, but may have been the straw that broke the camels back.
We wrote an OpenAPI spec for our existing API and just use it to generate documentation for external parties and it's worlds ahead of what we used to do.
I remember having a bunch of discussions about these issues when I worked on the Postman Collection Format (https://github.com/postmanlabs/postman-collection/blob/devel...) which can be very flexible.
Turns out there was a small red ("error" colored...) header bar near the top, collapsed by default. You need to click that to expand out all the API docs. Fun design.
Also Swagger.io people decided to replace the old editor with the new editor and it doesn't have many useful features the old has. Thankfully they kept the old one live.
Swagger is not all that hard to understand. This is a fantastic tutorial which helped a lot to get started: https://apihandyman.io/writing-openapi-swagger-specification...
You can declare types separately from APIs to make your last two items easier.
It works nicely with the django-rest-framework (both created by the same person) and has clients for python, javascript, and a command line tool to interact with the API. I have written a small python script that takes our CoreAPI specification and then generates markdown documentation around it.
The catch is that it is not as well documented as Swagger so working with it would require digging into its source code.
API Builder was started in 2014 as a free and open source project to build a community around best practices we learned scaling gilt.com and building flow.io.
Managing great APIs end to end at scale and over time take a huge investment in culture and tooling. API Builder solves a number of those problems.
A few reasons why teams adopt API Builder.
- Very, very high quality generated clients: Teams that use API Builder end up relying 100% on the generated clients - ie. the developers STOP writing and managing their own client SDKs, freeing up time to focus on product improvements.
- History: Every change in spec is documented - accurate and automatic - e.g. https://app.apibuilder.io/history?org=apicollective&app=apib...
- Resource centric: API Builder is resource first - instead of defining an operation explicitly, you define resources and then expose operations on that resource.
- Simple service specification: API Builder at its core separates the notion of the input format (e.g. api.json, swagger, avro) from the service description (service.json). This is a huge advantage: regardless of input format, the service specification can be fully expanded and complete.
- Simple input format: The default api.json format is simple for humans to write. It is JSON, but more than that it is approachable by a novice and designed to be both simple and easy.
- Easy to add code generators: Code generators in API Builder are themselves REST services which accept a service description (in JSON) and essentially return a string. Teams often write their own code generators - even small disposable ones - to systematically solve problems in an automated fashion.
- Testability of clients: With generated mock clients built from the same interface definition, teams can rely on mocks when building automated tests - and further use the provided mock clients to override only the specific features needed for a given test.
- Workflow that works with micro or mono repos and allows for concurrent, branched development of spec, service and client
More at https://www.apibuilder.io/ and https://app.apibuilder.io/doc/why
[edit: formatting]
It won't help you at all with unit testing (you shouldn't be using HTTP for that). You can theoretically use it to generate a client library in your language of choice for integration tests (true for Swagger, not yet for OpenAPI). Finally, there are tools built around it that let you play around with APIs that have these specs - Microsoft PowerBI comes to mind.
There are ways you could use it to build an API, but I wouldn't consider them a good idea. Edit: You could completely automate the process of ensuring that your semantic versions are compliant (i.e. you aren't breaking compatibility when you are claiming that you are not).
I'd be curious about implementation support as well. I was able to get it to work with earlier versions, but IIRC it involved using the apiKey in header auth type and manually adding "Bearer" to the auth header.
[
{
"name": "Spot",
"breed": "Dalmatian",
"sex": "male",
},
...
]
name,breed,sex
Spot,Dalmatian,male
For JSON HTTP APIs, Swagger makes a not-that-bad (IMO) attempt at describing the format of the structure.
The Unix philosophy, while it works well in specific cases, does not lend itself well to the creation of robot solutions. Parsing text streams with tools like sed/grep which are not the right tool for the job, in that they cannot understand the corner-cases of JSON/CSV/etc., leads to brittle solutions. (e.g., a use of sed/awk on the above CSV might work, until we get a more complicated format in a later iteration with a field containing an embedded newline, and our awk script falls down b/c we're not using a real CSV parser.)
This comment is overgeneralizing.