The document discusses the necessity and design of Software Development Kits (SDKs) in relation to Application Programming Interfaces (APIs). It outlines the advantages of SDKs, such as user-friendliness and client-side logic improvements, while emphasizing the importance of well-designed APIs first. The conclusion encourages providing SDKs if they add value and to prioritize API quality in development.

1. @LukasRosenstock
To SDK … or
not to SDK?

2. API abbr. Application Programming Interface n.
A remote interface available over HTTP(S),
designed in a REST or RPC style.

3. SDK abbr. Software Development Kit n.
A software library with the primary purpose
of wrapping an API for a specific language.

4. Server-2-Server Integrations
Server
Client
(web/native)
Third Party
Service
SDK
API
API

5. Interaction time :)

6. Why this talk?

7. Let‘s integrate Twilio SMS ...

8. … or like this:

9. Are SDKs really necessary?
And if not, why do I feel API providers force them on me?

10. For API Consumers
“SDKs introduce a complexity
cost over the lifetime of your
app that outweigh the gain of
not having to rewrite the code."
John Sheehan, Runscope (CA Inc.)

11. For API Providers
●
SDKs are additional effort →
– You can‘t have SDKs without APIs!
●
Is it worth it?

12. Coming up:
●
Advantages of SDKs
●
SDK Strategy
– Four Patterns
– Suggested Approach
●
Good SDK Design
●
Documenting APIs & SDKs
– Approahches
– Top API Provider Portal Showcase
●
Conclusion

13. Advantages of SDKs (1)
●
Beginner Friendly
– Easier to support!

14. Advantages of SDKs (2)
●
Client-side logic
– Caching
– Retrying
– Validation
– Idempotency
●
→ Robustness
●
→ Less Load

15. Advantages of SDKs (3)
●
Insights into API
usage from different
languages
– User Agent
– Monitoring
●
Opportunity to
connect with the
programming
community

16. Definitions from discussions
at APIStrat conference, 2016
SDK Strategy: Four Patterns
●
Provider-supported
●
Community-contributed
●
Consumer-driven
●
HTTP is the SDK

17. SDK Strategy: Suggested Approach
Design a great API
OpenAPI
Document it well
Release your spec
Embrace community SDKs
Release your own SDKs
TIME

18. Interlude
„Whatever people
can pull down from their
favorite package manager
is their developer experience.“
Cristiano Betta at APItheDocs
December 2017 in Amsterdam

19. Good SDK Design (1)
●
API Design comes first
– Add value over the API
– SDKs can‘t cover up bad APIs
●
Open Source is a MUST
●
Make SDK development a part of API testing

20. Good SDK Design (2)
Respect your target platform‘s approach first,
consistency within your API second.

21. Interlude
●
Can I auto-generated my SDKs?
– (+) Achieves presence and standardized
approach
– (-) No business-specific value-add

22. API & SDK Documentation
●
API-first, SDK-second
●
SDK-first, API-second
●
Integrated
●
Tutorials vs. Reference – different approaches
– Consistency?

23. Top API Provider Showcase

41. Conclusion
●
Provide SDKs if you can and believe there‘s
additional value or you want to support
beginners.
●
Don‘t forget the API over SDKs! Design both
well and respect them in your portal.