2. My Story
Can you please provide API Specification for
your existing Web Service?
3. THE Web Service specification
● Some .txt or .doc or email containing this...
https://my.company.api/v1/login
https://my.company.api/v1/user
https://my.company.api/v1/cards
https://my.company.api/v1/phones
https://my.company.api/v1/addresses
https://my.company.api/v1/addresses/1
4. THE Web Service specification v2
Push request for login using username, password and deviceId(UUID)
https://my.company.api/v1/login
Get user details
https://my.company.api/v1/user
Get list of cards
https://my.company.api/v1/cards
Get list of phones
https://my.company.api/v1/phones
•••
5. My approach
● Deciphering phase
o Postman
● Document Web Service
o Use template doc
● Verify specification docs with client
● Let the coding begin
7. Common issues
● Developers “LOVE” documentation
o new api calls
o modification of existing
o maintenance of Web Service Docs
● Consistency between platforms
o iOS, Android and IS
● Etc.
15. Outware’s approach
● Why v2.0?
o Why not v1.2 or v1.0
● Lots of reasons…
o Java vs Scala
● Works in both cases
o building API and client
o only client
16. Manually build the Specs
● How to check specs validity?
o JSON, YAML, blah blah blah...
17. Swagger Editor
● Available on v2
● Validation of Swagger syntax
● Visually attractive
Online Validator
● Swagger Validator Badge
<img src="http://online.swagger.io/validator?url={YOUR_URL}">
18. Swagger UI
● Web Service documentation
o Interactive
● Directly test API calls and observe the results
19. Put validation in action
● JSON Schema Validator
o https://github.com/ruby-json-schema/json-schema
● Validate models based on spec file
21. Swagger Codegen
● Generate client code based on spec
● Java / Maven project
● Output is auto generated ( & “documented code”)
● Multiple languages support
o Language client class
o Mustache template files
22. Android - How it works?
● Default setup - Out-Of-The-Box
o package, name, artefact id, version
● Run this command:
java -jar swagger-codegen-distribution-2.1.0.jar
-i http://petstore.swagger.io/v2/swagger.json
-l android
-o samples/client/petstore/android
● Use generated code as maven dependency in Android project
23. Custom Android example
● Extend AndroidClientCodegen.java
o make necessary changes (package, name, version, etc…)
25. What is the quality of generated code?
● Code as good as your template
o Treat as “Black Box”
● Using HTTPRequest
● Errors returned as string instead models
● Minor bugs
o array http params
o form params
26. What we wanted?
● Retrofit
● OKHttp
● Gradle
● Proper Error Handling
● Javadoc and Sources available in Android project
● Outware’s fork
https://github.com/outware-mobile/swagger-codegen
27. How to use?
● Generate Retrofit client
java -jar swagger-codegen-distribution-2.1.0.jar
-i http://petstore.swagger.io/v2/swagger.json
-l android-retrofit
-o samples/client/petstore/java
28. How to use?
● Local maven repo: Nexus or Artefactory (to publish .jar artefacts)
● Compile the generated code
o gradle build
o Jar files in (build/libs/*)
APIs
sources
javadoc
● Publish artefacts
o gradle uploadRelease
29. How to use?
● Set as project dependency in build.gradle
repositories {
maven {
url 'http://your_maven_repo'
}
}
...
dependencies {
compile 'com.wordnik:io.swagger.client:1.0.0'
compile 'com.squareup.retrofit:retrofit:1.8.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.1.0'
compile 'com.squareup.okhttp:okhttp:2.1.0'
}
30. iOS - How it works?
● Same as Android
● Default setup - Out-Of-The-Box
o generated files prefix
● Run this command:
java -jar swagger-codegen-distribution-2.1.0.jar
-i http://petstore.swagger.io/v2/swagger.json
-l objc
-o samples/client/petstore/objc
● Copy generated code and include into project
31. Custom iOS example
● Extend ObjcClientCodegen.java
o make changes (file prefix, etc…)
33. What we wanted
● AFNetworking v2
● Project dependency as Podspec
o similar approach as with Android
target :MyProject do
...
pod 'petstore-api'
end
● Error Message Handling - instead of returning NSError
● AppleDoc for API calls and models
34. Final piece of the puzzle
● Consistency
o versioning
o new api spec
o updated api spec
o bugfixes in templates
● The Web Service Repo
o both iOS and Android in same repo
● Automated in CI
o one click release
35. Approach Summary
● Design API specs using ‘Swagger Editor’
● Validate server responses with ‘Ruby JSON Schema Validator’
● Publish Swagger specs using ‘Swagger UI’
● Generate client code
o One repo for both iOS and Android
o Android as Maven dependency
o iOS as Podspec dependency
● Update project
o Small or Big Refactoring
36. Summary of Issues
● v2 in “development”
o Release 2.1.1-M1 on 18 Feb
● Bugs in the template files
● Not yet implemented
o Json schema model inheritance not supported
o Error model handling
o More languages support in v1.2
o Other issues
● Recompiling not efficient
o Poorly documented codebase
37. What’s next?
● Contribute to main repo
o Command line options
● Auth Support in Swagger
o Basic, OAuth v2.0, etc.
● Other new features
● Generating API integration stubs
● And FINALLY...
I’m going to talk about a magical way to approach web service APIs
My Story
All apps consume some way of a web services
Clients have existing web service and want an app
This is one of the first questions..
This is what we get...
TXT or WORD or even EMAIL
More details about the requests?
OK now I know more
It’s not their fault
So what do I do?
Decipher using Postman - manually hit the endpoints
We created a template for documenting APIs
Send to client to verify
Here is an example of that doc
Great, well documented, devs are happy…
But there are issues with this approach…
And that is… as you can see, the right alignment of the second table is wrong…
I’m joking, here are the common issues with this approach.
Devs LOVE documentation - that is a lie
Since we build both iOS and Android consistency is a problem.
Changes are not communicated to the other team.
So that’s why today I’ll talk about Swagger...
Question is…
WHAT IS SWAGGER
--------------------->
This is Swagger
Any questions?
Thank you all see ya next time
I was not familiar with the meaning of swagger so I’ve looked up in dictionary.
Going back to original question...
Simple yet powerful representation of your RESTful API
Group of projects with main focus on API documentation (7 main & over 50 community)
Impossible to cover all I’ll focus on the ones we use
To begin the explanation I want to start with the CORE
It’s a file JSON or YAML
Core is parser/generator/validator for the SPEC file
Request and response models are represented using JSON Schema V4
Here is an example how the api specs file looks like
<show json and explain>
How to create the spec, two main approaches automatic & manual
Automatic: Annotate code with swagger documentation to auto generate SPECS
Manual: Manually create SPEC using JSON or YAML
There are other approaches, dependent on how you build stuff, and which tools you use
BUT today I’m going to talk about our approach and what did work for us
First thing to mention is we are focusing only on V2
One reason is that before v2 the tools were build using Scala
The project did not get much love and contribution from the community (no one needs another language)
The creators came to decision to create V2 in Java
Based on my experience so far
In most cases we build both Web Service and client mobile app
But this approach works even if building just client mobile app
Now let’s look at our approach
First thing is to manually create the specification
YES, writing json or yaml is not cool at all
How is this supposed to help with better understanding of the Web Service
It’s more confusion than benefit…
That’s why we use tool…
Swagger Editor only available for V2
Offers validation and Visual representation of the spec
<Show it in action in browser>
Also there is online swagger syntax validator,
If you are paranoid about publishing your api, all tools can be hosted locally
Setup and deploy in less than 30min
Using the Editor we can make changes but
What if you Want to provide UI tool for devs/qa to review and not make changes to the file
Interactive web service documentation where you can test and observe the API calls and responses
<Show it in action in browser>
Now that we have documentation
How do we benefit even more from this specification?
What about if we can write tests to validate the server responses if they confirm the specs?
Here is how to do that:
Since we focus building IS mainly in Ruby...
We use Ruby Json Schema validator
<explain steps>
Load swagger YAML or JSON spec file
Grab the response from the server
Validate the returned json is compliant to the schema definition
So far we covered how to document and validate the responses
We have not mentioned anything about Android or iOS benefits.
Well there is more…
If we have all API specs why can’t we just generate the code and save time?
I present you Swagger Codegen
<Show Android Studio with SwaggerCodegen>
<show example>
To start with I’ll cover Android
Default package name
Default version
But what if I want to customize the parameters
Maven library from generated code
<show sample java>
Put it this way
Treat as black box but
devs not happy with code quality and implementation