SlideShare a Scribd company logo
Building Your API 
for Longevity 
by mike stowe 
l All contents Copyright © 2014, MuleSoft Inc.
Disclaimer 
This talk is not about how to code your 
API, but rather to show you what steps and 
best practices you need to utilize to build 
a successful, long-lived API to the extent 
that we can in 45 minutes. 
l All contents Copyright © 2014, MuleSoft Inc.
About Me 
• API Fanatic 
• Open Source Contributor 
• Author, Speaker, Consultant 
• 10+ years hacking Professional Code 
• Dev Relations Manager at MuleSoft 
l All contents Copyright © 2014, MuleSoft Inc.
APIs are changing the 
world. 
l All contents Copyright © 2014, MuleSoft Inc.
Over 13,000 PUBLIC APIs 
l All contents Copyright © 2014, MuleSoft Inc.
l All contents Copyright © 2014, MuleSoft Inc.
Today APIs are connecting… 
l All contents Copyright © 2014, MuleSoft Inc.
PHONES 
l All contents Copyright © 2014, MuleSoft Inc.
WATCHES 
l All contents Copyright © 2014, MuleSoft Inc.
GLASSES 
l All contents Copyright © 2014, MuleSoft Inc.
CARS 
l All contents Copyright © 2014, MuleSoft Inc.
REFRIGERATORS 
l All contents Copyright © 2014, MuleSoft Inc.
THERMOSTATS 
l All contents Copyright © 2014, MuleSoft Inc.
l All contents Copyright © 2014, MuleSoft Inc. 
IN HOME 
ROBOTS
AND MORE 
l All contents Copyright © 2014, MuleSoft Inc.
THINK ABOUT THAT… 
l All contents Copyright © 2014, MuleSoft Inc.
In order to work, the IoT 
requires that APIs remain 
persistent. 
l All contents Copyright © 2014, MuleSoft Inc.
l All contents Copyright © 2014, MuleSoft Inc. 
+
Versioning and making 
changes is expensive… 
l All contents Copyright © 2014, MuleSoft Inc.
FOR EVERYONE. 
l All contents Copyright © 2014, MuleSoft Inc.
Thankfully with 5 Simple 
Steps you can build an API 
that is designed to last. 
l All contents Copyright © 2014, MuleSoft Inc.
They are: 
1 – Go in with a long-term mindset 
2 – Understand what you’re building 
3 – Utilize Spec Driven Development 
4 – Incorporate Best Practices 
5 – Repeat steps 1-4 for all new features 
l All contents Copyright © 2014, MuleSoft Inc.
Think Long-term: 
• Your API is a Contract 
• Versioning is not a solution 
• Understand you suck at design 
• You can pay a little now, or much more later 
• You need to think things through 
• Mind-set is everything 
l All contents Copyright © 2014, MuleSoft Inc.
Your Users are Depending on You… 
Your API is a contract, it’s your word to 
your users. Users who are not only 
depending on a working API to integrate 
with your service, but in order to provide 
food for their families. 
l All contents Copyright 24 © 2014, MuleSoft Inc.
This means you need to think through every 
aspect of your API before building it. 
l All contents Copyright © 2014, MuleSoft Inc.
Thinking things through… 
• Who is your API for? 
• What type of API are you building? 
• How are you going to maintain your API? 
• How are you going to document your API? 
• How are you going to let users interact with your API? 
• How are you going to manage authentication, 
provisioning, throttling, and developer security? 
• How are you going to protect your servers against 
attacks, developer misuse, etc? 
• How are you going to manage support? 
l All contents Copyright 26 © 2014, MuleSoft Inc.
Who Will Be Using Your API? 
• Who are your end users? 
- Current customers 
- Business partners 
- Third-party services 
• What actions do they need access to? 
- This means sitting down and talking to them! 
• How can you involve them in the design process? 
- Your users should be involved from Day One. 
l All contents Copyright 27 © 2014, MuleSoft Inc.
What is the Purpose of Your API? 
• List out WHY you are making the API 
- Saying that you’re exposing your data to users is not 
good enough- explain HOW they will use it 
• Explain how your API will interact with existing 
services 
• List out the actions the API needs to be able to handle 
- Users: add, edit, reset password, delete, etc… 
- Messages: draft, send, retrieve, archive, etc… 
• Do only what is NECESSARY 
• DON’T get fancy. 
l All contents Copyright 28 © 2014, MuleSoft Inc.
List Out What Your Users Need to be able to Do: 
l All contents Copyright 29 © 2014, MuleSoft Inc.
What Type of API Are You Building? 
• Are you building a REST, partial REST, SOAP, or RPC 
based API? 
• Why are you building your API in that format? 
• What does that mean for development? 
• What does that mean for usability? 
• What does that mean for longevity? 
l All contents Copyright 30 © 2014, MuleSoft Inc.
What Type of API Are You Building? 
l All contents Copyright 31 © 2014, MuleSoft Inc.
Do You Understand the REST Constraints? 
• Client-Server 
• Stateless 
• Cacheable 
• Interface/ Uniform Contract 
• Layered System 
• Code on Demand (optional) 
l All contents Copyright 32 © 2014, MuleSoft Inc.
Most APIs are NOT RESTful. 
l All contents Copyright © 2014, MuleSoft Inc.
This is why it’s so important to understand 
the different types of APIs, why each type is 
different, and why you are choosing one 
over the other. 
l All contents Copyright © 2014, MuleSoft Inc.
It also means building your API for beyond 
today… 
l All contents Copyright © 2014, MuleSoft Inc.
...people are fairly good at short-term 
design, and usually awful at long-term 
design.” 
“ 
l All contents Copyright 36 © 2014, MuleSoft Inc. 
-Dr. Roy Fielding
Versioning is a necessary evil. 
l All contents Copyright © 2014, MuleSoft Inc.
Problems with Versioning 
• Backwards incompatibilities 
• Multiple Services to Maintain 
• Multiple Systems to Support 
• Creates confusion among developers 
• Developer adoption is nearly impossible 
l All contents Copyright 38 © 2014, MuleSoft Inc.
You Need to Version When: 
• Backwards incompatible platform changes 
• Your API is no longer extendable 
• Your spec is out dated (ie SOAP) 
l All contents Copyright 39 © 2014, MuleSoft Inc.
But You Shouldn’t Version Just Because You: 
• Added new endpoints 
• Added additional data in response 
• Changed technologies (java toruby) 
• Changed your application’s services (code) 
l All contents Copyright 40 © 2014, MuleSoft Inc.
Versioning does not excuse poor design. 
l All contents Copyright © 2014, MuleSoft Inc.
And a poorly designed API will cost you far 
more in the long run, adding months to fix what 
could have been prevented in weeks. There are 
no shortcuts or quick fixes, you can either build 
your API the right way to begin with, or pay 
substantially for it in the long-run. 
l All contents Copyright © 2014, MuleSoft Inc.
Use Spec Driven Development 
• Define your API before Coding 
• Use Design Patterns/ Code Reuse 
• Mock and get User Feedback 
• Make Necessary Changes 
• Start Coding – to the Spec 
• DO NOT DEVIATE! 
l All contents Copyright © 2014, MuleSoft Inc.
Spec Driven Development means a hybrid 
between agile and waterfall methodologies. 
You should develop your spec iteratively, 
incorporating agile user testing. However, 
the actual development (coding) of your API 
should be static, driven by the spec with no 
deviation. 
l All contents Copyright © 2014, MuleSoft Inc.
Disclaimer: Waterfall refers to the spec and 
changing the spec only! You should still use 
sprints for code development – just at this 
point the spec should not be changing. 
l All contents Copyright © 2014, MuleSoft Inc.
Hybrid Approach 
Design Development 
Continuous, fluid, changeable Static… No turns 
l All contents Copyright 46 © 2014, MuleSoft Inc.
The Agile Design Cycle 
l All contents Copyright 47 © 2014, MuleSoft Inc.
The goal is that by utilizing agile user 
testing, carefully designing, and 
prototyping your API in an iterative state, 
that most design related issues have 
already been discovered and resolved. 
Allowing you to develop fearlessly. 
l All contents Copyright © 2014, MuleSoft Inc.
The problem is up until now, designing and 
prototyping an API has been extremely 
costly. Requiring developers to create a 
mock API through extensive coding, and 
without any real constraints/ pattern reuse. 
l All contents Copyright © 2014, MuleSoft Inc.
However, there are several new specs being 
driven by today’s industry leaders making it 
easier define your API: with tools to design, 
prototype, document, and allow user 
interaction. 
l All contents Copyright © 2014, MuleSoft Inc.
Some of Today’s Specs: 
• RAML 
• IO Docs 
• Swagger 
• API Blueprint 
l All contents Copyright 51 © 2014, MuleSoft Inc.
Using RAML You Can: 
• You can define your API in just a few lines of code 
• You can see what it would look like as you go 
• You can quickly prototype it for devs to try 
• You can quickly make tweaks/ changes 
• You can easily document your API 
• You can let developers try your API online 
• You can let developers interact with your and other APIs 
• Generate SDKs/ client libraries for your API (APIMatic.io) 
l All contents Copyright 52 © 2014, MuleSoft Inc.
More Importantly… 
• You can use design patterns 
• You can reuse code (traits, resourceTypes) 
resourceTypes: 
-­‐ 
collection: 
description: 
Collection 
of 
available 
<<resourcePathName>> 
in 
Jukebox. 
get: 
description: 
Get 
a 
list 
of 
<<resourcePathName>>. 
responses: 
200: 
body: 
application/json: 
example: 
| 
<<exampleCollection>> 
l All contents Copyright 53 © 2014, MuleSoft Inc.
The RAML API Designer 
l All contents Copyright 54 © 2014, MuleSoft Inc.
What Does RAML Look Like? 
#%RAML 
0.8 
title: 
World 
Music 
API 
baseUri: 
http://example.api.com/{version} 
version: 
v1 
/playlists: 
get: 
responses: 
200: 
body: 
application/json: 
example: 
| 
{ 
“playlistID” 
: 
1, 
“playlistName” 
: 
“My 
Awesome 
Playlist”, 
“genre” 
: 
“top40”, 
“songs” 
: 
40 
} 
l All contents Copyright 55 © 2014, MuleSoft Inc.
Remember, your spec is not a one-and-done, 
rather it is the blueprint for your API. 
Anytime you do something to your API you 
should be modifying the spec and going 
through user testing before writing code. 
You should never have code that does 
something not defined by your spec. 
l All contents Copyright © 2014, MuleSoft Inc.
Incorporate Best Practices: 
• Use Nouns 
• Use CRUD 
• Use Hypermedia (HATEOAS) 
• Use Accept/ Content-Type 
• Return Header Codes 
• Return Descriptive Error Messages 
l All contents Copyright © 2014, MuleSoft Inc.
Use Nouns. 
l All contents Copyright © 2014, MuleSoft Inc.
Use: 
/users 
Not: 
/createUser 
/getUser 
/deleteUser 
l All contents Copyright © 2014, MuleSoft Inc.
Utilize CRUD. 
l All contents Copyright © 2014, MuleSoft Inc.
Create (POST) 
Read (GET) 
Update (PUT/ 
l All contents Copyright © 2014, MuleSoft Inc. 
PATCH) 
Delete (DELETE)
Use Hypermedia. 
l All contents Copyright © 2014, MuleSoft Inc. 
HATEOAS
Most Popular Hypertext Link Specs 
• HAL 
• JSON-LD 
• JSON API 
• Siren 
l All contents Copyright 63 © 2014, MuleSoft Inc.
{ 
"data" 
: 
{ 
"user": 
{ 
"fname":"first", 
"lname":"last" 
} 
}, 
"_links" 
: 
{ 
"edit": 
{ 
"href" 
: 
"/api/user/id/1" 
}, 
"message": 
{ 
"href" 
: 
"/api/message/id/1/lname/last" 
} 
} 
} 
l All contents Copyright © 2014, MuleSoft Inc. 
HAL
Use Accept/ Content-Type 
Headers. 
l All contents Copyright © 2014, MuleSoft Inc.
Use Accept/ Content-Type Headers 
Using headers gives you flexibility to support multiple 
types of formats from the same resource without 
worrying about breaking backwards compatibility. 
Most common: 
• application/json - wider language support 
• application/xml 
l All contents Copyright 66 © 2014, MuleSoft Inc.
Use Response Codes. 
l All contents Copyright © 2014, MuleSoft Inc.
• 200 – OK 
• 201 – Created 
• 304 – Not modified 
• 400 – Bad Request 
• 401 – Not Authorized 
• 403 – Forbidden 
• 404 – Page/ Resource Not Found 
• 405 – Method Not Allowed 
• 415 – Unsupported Media Type 
• 500 – Internal Server Error 
l All contents Copyright © 2014, MuleSoft Inc.
Or if you’re feeling super creative… 
• 418 – I’m a Teapot… 
• 420 – Enhance Your Calm 
l All contents Copyright © 2014, MuleSoft Inc.
Use Descriptive Error Messages. 
l All contents Copyright © 2014, MuleSoft Inc.
The more information you provide, the easier it will be 
for developers to integrate your API without contacting 
Support. 
{ 
'exception' 
{ 
'code' 
: 
'e3526', 
'message' 
: 
'Missing 
UserID', 
'description' 
: 
'A 
UserID 
is 
required 
to 
edit 
a 
user.', 
'link' 
: 
'http://docs.mysite.com/errors/e3526/' 
} 
} 
l All contents Copyright © 2014, MuleSoft Inc.
Also be sure to keep your documentation up 
to date and simple enough for developers to 
quickly find and implement solutions to 
even the most complex problems. Poor 
documentation has been the death of many 
an API. 
l All contents Copyright © 2014, MuleSoft Inc.
Finally, when adding new things 
to your API, be sure to: 
l All contents Copyright © 2014, MuleSoft Inc.
Finally, when adding new things 
to your API, be sure to: 
1 – Go in with a long-term mindset 
2 – Understand what you’re building 
3 – Utilize Spec Driven Development 
4 – Incorporate Best Practices 
l All contents Copyright © 2014, MuleSoft Inc.
It only takes ONE little thing to significantly 
reduce your API’s life span. Every action you 
make on your API must be carefully thought 
out and tested BEFORE being pushed to 
production. 
l All contents Copyright © 2014, MuleSoft Inc.
Remember... 
l All contents Copyright © 2014, MuleSoft Inc.
Building an API is easy. 
l All contents Copyright © 2014, MuleSoft Inc.
Designing an API is hard. 
l All contents Copyright © 2014, MuleSoft Inc.
l All contents Copyright © 2014, MuleSoft Inc. 
read more @ 
blogs.mulesoft.org
l All contents Copyright © 2014, MuleSoft Inc. 
@MuleDev 
www.mulesoft.com

More Related Content

What's hot

API SDK Development – Lessons Learned
API SDK Development – Lessons LearnedAPI SDK Development – Lessons Learned
API SDK Development – Lessons Learned
Pronovix
 
Open API Initiative: Six months and counting
Open API Initiative: Six months and countingOpen API Initiative: Six months and counting
Open API Initiative: Six months and counting
Open API Initiative (OAI)
 
APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes...
APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes...APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes...
APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes...
apidays
 
APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...
APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...
APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...
apidays
 
End to End Testing: Bug Squashing for API Developers
End to End Testing: Bug Squashing for API Developers End to End Testing: Bug Squashing for API Developers
End to End Testing: Bug Squashing for API Developers
Apigee | Google Cloud
 
INTERFACE, by apidays - Low code APIs that don't break by Zdenek Nemec, Supe...
INTERFACE, by apidays  - Low code APIs that don't break by Zdenek Nemec, Supe...INTERFACE, by apidays  - Low code APIs that don't break by Zdenek Nemec, Supe...
INTERFACE, by apidays - Low code APIs that don't break by Zdenek Nemec, Supe...
apidays
 
How Customers are Building and Using their Own Connectors
How Customers are Building and Using their Own ConnectorsHow Customers are Building and Using their Own Connectors
How Customers are Building and Using their Own Connectors
MuleSoft
 
API documentation
API documentationAPI documentation
API documentation
Anindita Basu
 
API-first, going beyond SOA, ESB & Integration
API-first, going beyond SOA, ESB & IntegrationAPI-first, going beyond SOA, ESB & Integration
API-first, going beyond SOA, ESB & Integration
Apigee | Google Cloud
 
OpenAPI 3.0, And What It Means for the Future of Swagger
OpenAPI 3.0, And What It Means for the Future of SwaggerOpenAPI 3.0, And What It Means for the Future of Swagger
OpenAPI 3.0, And What It Means for the Future of Swagger
SmartBear
 
Api-First service design
Api-First service designApi-First service design
Api-First service design
Stefaan Ponnet
 
apidays Paris 2019 - How Do Async APIs Survive in a Rest World? by Luca Ferra...
apidays Paris 2019 - How Do Async APIs Survive in a Rest World? by Luca Ferra...apidays Paris 2019 - How Do Async APIs Survive in a Rest World? by Luca Ferra...
apidays Paris 2019 - How Do Async APIs Survive in a Rest World? by Luca Ferra...
apidays
 
Transforming Your Business Through APIs
Transforming Your Business Through APIsTransforming Your Business Through APIs
Transforming Your Business Through APIs
Apigee | Google Cloud
 
MuleSoft Meetup Winnipeg: Maiden Edition
MuleSoft Meetup Winnipeg: Maiden EditionMuleSoft Meetup Winnipeg: Maiden Edition
MuleSoft Meetup Winnipeg: Maiden Edition
MannaAkpan
 
APIdays Paris 2019 - Improve the Security of Your APIs by Securing the API Li...
APIdays Paris 2019 - Improve the Security of Your APIs by Securing the API Li...APIdays Paris 2019 - Improve the Security of Your APIs by Securing the API Li...
APIdays Paris 2019 - Improve the Security of Your APIs by Securing the API Li...
apidays
 
Modernize Service-Oriented Architecture with APIs
Modernize Service-Oriented Architecture with APIsModernize Service-Oriented Architecture with APIs
Modernize Service-Oriented Architecture with APIs
Apigee | Google Cloud
 
Standardizing APIs Across Your Organization with Swagger and OAS | A SmartBea...
Standardizing APIs Across Your Organization with Swagger and OAS | A SmartBea...Standardizing APIs Across Your Organization with Swagger and OAS | A SmartBea...
Standardizing APIs Across Your Organization with Swagger and OAS | A SmartBea...
SmartBear
 
APIs in the Enterprise - Lessons Learned
APIs in the Enterprise - Lessons Learned APIs in the Enterprise - Lessons Learned
APIs in the Enterprise - Lessons Learned
Apigee | Google Cloud
 

What's hot (18)

API SDK Development – Lessons Learned
API SDK Development – Lessons LearnedAPI SDK Development – Lessons Learned
API SDK Development – Lessons Learned
 
Open API Initiative: Six months and counting
Open API Initiative: Six months and countingOpen API Initiative: Six months and counting
Open API Initiative: Six months and counting
 
APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes...
APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes...APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes...
APIdays Paris 2019 - Microservices vs Miniservices vs Monoliths: Winner Takes...
 
APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...
APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...
APIdays Paris 2019 - API Security Tips for Developers by Isabelle Mauny, 42Cr...
 
End to End Testing: Bug Squashing for API Developers
End to End Testing: Bug Squashing for API Developers End to End Testing: Bug Squashing for API Developers
End to End Testing: Bug Squashing for API Developers
 
INTERFACE, by apidays - Low code APIs that don't break by Zdenek Nemec, Supe...
INTERFACE, by apidays  - Low code APIs that don't break by Zdenek Nemec, Supe...INTERFACE, by apidays  - Low code APIs that don't break by Zdenek Nemec, Supe...
INTERFACE, by apidays - Low code APIs that don't break by Zdenek Nemec, Supe...
 
How Customers are Building and Using their Own Connectors
How Customers are Building and Using their Own ConnectorsHow Customers are Building and Using their Own Connectors
How Customers are Building and Using their Own Connectors
 
API documentation
API documentationAPI documentation
API documentation
 
API-first, going beyond SOA, ESB & Integration
API-first, going beyond SOA, ESB & IntegrationAPI-first, going beyond SOA, ESB & Integration
API-first, going beyond SOA, ESB & Integration
 
OpenAPI 3.0, And What It Means for the Future of Swagger
OpenAPI 3.0, And What It Means for the Future of SwaggerOpenAPI 3.0, And What It Means for the Future of Swagger
OpenAPI 3.0, And What It Means for the Future of Swagger
 
Api-First service design
Api-First service designApi-First service design
Api-First service design
 
apidays Paris 2019 - How Do Async APIs Survive in a Rest World? by Luca Ferra...
apidays Paris 2019 - How Do Async APIs Survive in a Rest World? by Luca Ferra...apidays Paris 2019 - How Do Async APIs Survive in a Rest World? by Luca Ferra...
apidays Paris 2019 - How Do Async APIs Survive in a Rest World? by Luca Ferra...
 
Transforming Your Business Through APIs
Transforming Your Business Through APIsTransforming Your Business Through APIs
Transforming Your Business Through APIs
 
MuleSoft Meetup Winnipeg: Maiden Edition
MuleSoft Meetup Winnipeg: Maiden EditionMuleSoft Meetup Winnipeg: Maiden Edition
MuleSoft Meetup Winnipeg: Maiden Edition
 
APIdays Paris 2019 - Improve the Security of Your APIs by Securing the API Li...
APIdays Paris 2019 - Improve the Security of Your APIs by Securing the API Li...APIdays Paris 2019 - Improve the Security of Your APIs by Securing the API Li...
APIdays Paris 2019 - Improve the Security of Your APIs by Securing the API Li...
 
Modernize Service-Oriented Architecture with APIs
Modernize Service-Oriented Architecture with APIsModernize Service-Oriented Architecture with APIs
Modernize Service-Oriented Architecture with APIs
 
Standardizing APIs Across Your Organization with Swagger and OAS | A SmartBea...
Standardizing APIs Across Your Organization with Swagger and OAS | A SmartBea...Standardizing APIs Across Your Organization with Swagger and OAS | A SmartBea...
Standardizing APIs Across Your Organization with Swagger and OAS | A SmartBea...
 
APIs in the Enterprise - Lessons Learned
APIs in the Enterprise - Lessons Learned APIs in the Enterprise - Lessons Learned
APIs in the Enterprise - Lessons Learned
 

Similar to Building Your API for Longevity

MuleSoft Meetup slides_kualalumpur_19thSept_Undisturbed REST: Achieving Undis...
MuleSoft Meetup slides_kualalumpur_19thSept_Undisturbed REST: Achieving Undis...MuleSoft Meetup slides_kualalumpur_19thSept_Undisturbed REST: Achieving Undis...
MuleSoft Meetup slides_kualalumpur_19thSept_Undisturbed REST: Achieving Undis...
Manish Kumar Yadav
 
Building a REST API for Longevity
Building a REST API for LongevityBuilding a REST API for Longevity
Building a REST API for Longevity
MuleSoft
 
Effective API Design
Effective API DesignEffective API Design
Effective API Design
Bansilal Haudakari
 
Accessibility testing technology, human touch and value
Accessibility testing technology, human touch and value Accessibility testing technology, human touch and value
Accessibility testing technology, human touch and value
Srinivasu Chakravarthula
 
Manila MuleSoft Meetup #4 January 2019
Manila MuleSoft Meetup #4 January 2019Manila MuleSoft Meetup #4 January 2019
Manila MuleSoft Meetup #4 January 2019
Christopher Co
 
Building the Eventbrite API Ecosystem
Building the Eventbrite API EcosystemBuilding the Eventbrite API Ecosystem
Building the Eventbrite API Ecosystem
Mitch Colleran
 
10 steps to design and build the perfect
10 steps to design and build the perfect10 steps to design and build the perfect
10 steps to design and build the perfect
Son Nguyen
 
Making Sense of Hypermedia APIs – Hype or Reality?
Making Sense of Hypermedia APIs – Hype or Reality?Making Sense of Hypermedia APIs – Hype or Reality?
Making Sense of Hypermedia APIs – Hype or Reality?
Akana
 
Scaling API Design - Nordic APIs 2014
Scaling API Design - Nordic APIs 2014Scaling API Design - Nordic APIs 2014
Scaling API Design - Nordic APIs 2014
Jason Harmon
 
Scaling API Design
Scaling API DesignScaling API Design
Scaling API Design
Jason Harmon
 
Lessons learned on the Azure API Stewardship Journey.pptx
Lessons learned on the Azure API Stewardship Journey.pptxLessons learned on the Azure API Stewardship Journey.pptx
Lessons learned on the Azure API Stewardship Journey.pptx
apidays
 
Scaling API Design
Scaling API DesignScaling API Design
Scaling API Design
Jason Harmon
 
API Frenzy: The Implications and Planning for a Successful API Strategy
API Frenzy: The Implications and Planning for a Successful API StrategyAPI Frenzy: The Implications and Planning for a Successful API Strategy
API Frenzy: The Implications and Planning for a Successful API Strategy
Akana
 
Api frenzy june 2013 v2
Api frenzy june 2013 v2Api frenzy june 2013 v2
Api frenzy june 2013 v2
Sachin Agarwal
 
Managing APIs with MuleSoft
Managing APIs with MuleSoftManaging APIs with MuleSoft
Managing APIs with MuleSoft
Guilherme Pereira Silva
 
API Description Languages
API Description LanguagesAPI Description Languages
API Description Languages
Akana
 
API Description Languages
API Description LanguagesAPI Description Languages
API Description Languages
Akana
 
API-Consumption compressed (1)
API-Consumption compressed (1)API-Consumption compressed (1)
API-Consumption compressed (1)
Rahul Ghai
 
API Economy - Cuomo
API Economy - Cuomo API Economy - Cuomo
API Economy - Cuomo
Prolifics
 
oracle-apac-developers-meetup-2-building-api-with-apiary-slides
oracle-apac-developers-meetup-2-building-api-with-apiary-slidesoracle-apac-developers-meetup-2-building-api-with-apiary-slides
oracle-apac-developers-meetup-2-building-api-with-apiary-slides
Boopathy Balasubramanian
 

Similar to Building Your API for Longevity (20)

MuleSoft Meetup slides_kualalumpur_19thSept_Undisturbed REST: Achieving Undis...
MuleSoft Meetup slides_kualalumpur_19thSept_Undisturbed REST: Achieving Undis...MuleSoft Meetup slides_kualalumpur_19thSept_Undisturbed REST: Achieving Undis...
MuleSoft Meetup slides_kualalumpur_19thSept_Undisturbed REST: Achieving Undis...
 
Building a REST API for Longevity
Building a REST API for LongevityBuilding a REST API for Longevity
Building a REST API for Longevity
 
Effective API Design
Effective API DesignEffective API Design
Effective API Design
 
Accessibility testing technology, human touch and value
Accessibility testing technology, human touch and value Accessibility testing technology, human touch and value
Accessibility testing technology, human touch and value
 
Manila MuleSoft Meetup #4 January 2019
Manila MuleSoft Meetup #4 January 2019Manila MuleSoft Meetup #4 January 2019
Manila MuleSoft Meetup #4 January 2019
 
Building the Eventbrite API Ecosystem
Building the Eventbrite API EcosystemBuilding the Eventbrite API Ecosystem
Building the Eventbrite API Ecosystem
 
10 steps to design and build the perfect
10 steps to design and build the perfect10 steps to design and build the perfect
10 steps to design and build the perfect
 
Making Sense of Hypermedia APIs – Hype or Reality?
Making Sense of Hypermedia APIs – Hype or Reality?Making Sense of Hypermedia APIs – Hype or Reality?
Making Sense of Hypermedia APIs – Hype or Reality?
 
Scaling API Design - Nordic APIs 2014
Scaling API Design - Nordic APIs 2014Scaling API Design - Nordic APIs 2014
Scaling API Design - Nordic APIs 2014
 
Scaling API Design
Scaling API DesignScaling API Design
Scaling API Design
 
Lessons learned on the Azure API Stewardship Journey.pptx
Lessons learned on the Azure API Stewardship Journey.pptxLessons learned on the Azure API Stewardship Journey.pptx
Lessons learned on the Azure API Stewardship Journey.pptx
 
Scaling API Design
Scaling API DesignScaling API Design
Scaling API Design
 
API Frenzy: The Implications and Planning for a Successful API Strategy
API Frenzy: The Implications and Planning for a Successful API StrategyAPI Frenzy: The Implications and Planning for a Successful API Strategy
API Frenzy: The Implications and Planning for a Successful API Strategy
 
Api frenzy june 2013 v2
Api frenzy june 2013 v2Api frenzy june 2013 v2
Api frenzy june 2013 v2
 
Managing APIs with MuleSoft
Managing APIs with MuleSoftManaging APIs with MuleSoft
Managing APIs with MuleSoft
 
API Description Languages
API Description LanguagesAPI Description Languages
API Description Languages
 
API Description Languages
API Description LanguagesAPI Description Languages
API Description Languages
 
API-Consumption compressed (1)
API-Consumption compressed (1)API-Consumption compressed (1)
API-Consumption compressed (1)
 
API Economy - Cuomo
API Economy - Cuomo API Economy - Cuomo
API Economy - Cuomo
 
oracle-apac-developers-meetup-2-building-api-with-apiary-slides
oracle-apac-developers-meetup-2-building-api-with-apiary-slidesoracle-apac-developers-meetup-2-building-api-with-apiary-slides
oracle-apac-developers-meetup-2-building-api-with-apiary-slides
 

More from MuleSoft

The CIO's Guide to Digital Transformation
The CIO's Guide to Digital TransformationThe CIO's Guide to Digital Transformation
The CIO's Guide to Digital Transformation
MuleSoft
 
Gluecon 2017: Metadata is the Glue
Gluecon 2017: Metadata is the GlueGluecon 2017: Metadata is the Glue
Gluecon 2017: Metadata is the Glue
MuleSoft
 
Gluecon 2017: API Modelling Framework - A Toolbox for Interacting With API S...
Gluecon 2017: API Modelling Framework -  A Toolbox for Interacting With API S...Gluecon 2017: API Modelling Framework -  A Toolbox for Interacting With API S...
Gluecon 2017: API Modelling Framework - A Toolbox for Interacting With API S...
MuleSoft
 
How to Get Unstuck
How to Get Unstuck How to Get Unstuck
How to Get Unstuck
MuleSoft
 
Product Vision and Roadmap for Anypoint Platform
Product Vision and Roadmap for Anypoint PlatformProduct Vision and Roadmap for Anypoint Platform
Product Vision and Roadmap for Anypoint Platform
MuleSoft
 
How API Enablement Drives Legacy Modernization
How API Enablement Drives Legacy ModernizationHow API Enablement Drives Legacy Modernization
How API Enablement Drives Legacy Modernization
MuleSoft
 
Microservices on Anypoint Platform
Microservices on Anypoint PlatformMicroservices on Anypoint Platform
Microservices on Anypoint Platform
MuleSoft
 
Applying UX principles and methods to APIs
Applying UX principles and methods to APIs Applying UX principles and methods to APIs
Applying UX principles and methods to APIs
MuleSoft
 
Secure by design: Scaling security across the enterprise
Secure by design: Scaling security across the enterpriseSecure by design: Scaling security across the enterprise
Secure by design: Scaling security across the enterprise
MuleSoft
 
Gathering Operational Intelligence in Complex Environments at Splunk
Gathering Operational Intelligence in Complex Environments at SplunkGathering Operational Intelligence in Complex Environments at Splunk
Gathering Operational Intelligence in Complex Environments at Splunk
MuleSoft
 
CloudHub and other Cloud Deployment Options
CloudHub and other Cloud Deployment OptionsCloudHub and other Cloud Deployment Options
CloudHub and other Cloud Deployment Options
MuleSoft
 
Governing and Sharing your Integration Assets
Governing and Sharing your Integration AssetsGoverning and Sharing your Integration Assets
Governing and Sharing your Integration Assets
MuleSoft
 
MuleSoft's Approach to Driving Customer Outcomes
MuleSoft's Approach to Driving Customer Outcomes MuleSoft's Approach to Driving Customer Outcomes
MuleSoft's Approach to Driving Customer Outcomes
MuleSoft
 
Designing and building Mule applications
Designing and building Mule applicationsDesigning and building Mule applications
Designing and building Mule applications
MuleSoft
 
Object Store
Object StoreObject Store
Object Store
MuleSoft
 
Introducing Anypoint Exchange 2.0
Introducing Anypoint Exchange 2.0Introducing Anypoint Exchange 2.0
Introducing Anypoint Exchange 2.0
MuleSoft
 
Troubleshooting Anypoint Platform
Troubleshooting Anypoint PlatformTroubleshooting Anypoint Platform
Troubleshooting Anypoint Platform
MuleSoft
 
Relevancy in a Rapidly Changing World (Yvonne Wassenaar)
Relevancy in a Rapidly Changing World (Yvonne Wassenaar)Relevancy in a Rapidly Changing World (Yvonne Wassenaar)
Relevancy in a Rapidly Changing World (Yvonne Wassenaar)
MuleSoft
 
Leveraging APIs and the Cloud to Transform Veteran Care (Steve Rushing)
Leveraging APIs and the Cloud to Transform Veteran Care (Steve Rushing)Leveraging APIs and the Cloud to Transform Veteran Care (Steve Rushing)
Leveraging APIs and the Cloud to Transform Veteran Care (Steve Rushing)
MuleSoft
 
Role of Technology in the Evolution of P&C Insurance (Marcus Ryu)
Role of Technology in the Evolution of P&C Insurance (Marcus Ryu)Role of Technology in the Evolution of P&C Insurance (Marcus Ryu)
Role of Technology in the Evolution of P&C Insurance (Marcus Ryu)
MuleSoft
 

More from MuleSoft (20)

The CIO's Guide to Digital Transformation
The CIO's Guide to Digital TransformationThe CIO's Guide to Digital Transformation
The CIO's Guide to Digital Transformation
 
Gluecon 2017: Metadata is the Glue
Gluecon 2017: Metadata is the GlueGluecon 2017: Metadata is the Glue
Gluecon 2017: Metadata is the Glue
 
Gluecon 2017: API Modelling Framework - A Toolbox for Interacting With API S...
Gluecon 2017: API Modelling Framework -  A Toolbox for Interacting With API S...Gluecon 2017: API Modelling Framework -  A Toolbox for Interacting With API S...
Gluecon 2017: API Modelling Framework - A Toolbox for Interacting With API S...
 
How to Get Unstuck
How to Get Unstuck How to Get Unstuck
How to Get Unstuck
 
Product Vision and Roadmap for Anypoint Platform
Product Vision and Roadmap for Anypoint PlatformProduct Vision and Roadmap for Anypoint Platform
Product Vision and Roadmap for Anypoint Platform
 
How API Enablement Drives Legacy Modernization
How API Enablement Drives Legacy ModernizationHow API Enablement Drives Legacy Modernization
How API Enablement Drives Legacy Modernization
 
Microservices on Anypoint Platform
Microservices on Anypoint PlatformMicroservices on Anypoint Platform
Microservices on Anypoint Platform
 
Applying UX principles and methods to APIs
Applying UX principles and methods to APIs Applying UX principles and methods to APIs
Applying UX principles and methods to APIs
 
Secure by design: Scaling security across the enterprise
Secure by design: Scaling security across the enterpriseSecure by design: Scaling security across the enterprise
Secure by design: Scaling security across the enterprise
 
Gathering Operational Intelligence in Complex Environments at Splunk
Gathering Operational Intelligence in Complex Environments at SplunkGathering Operational Intelligence in Complex Environments at Splunk
Gathering Operational Intelligence in Complex Environments at Splunk
 
CloudHub and other Cloud Deployment Options
CloudHub and other Cloud Deployment OptionsCloudHub and other Cloud Deployment Options
CloudHub and other Cloud Deployment Options
 
Governing and Sharing your Integration Assets
Governing and Sharing your Integration AssetsGoverning and Sharing your Integration Assets
Governing and Sharing your Integration Assets
 
MuleSoft's Approach to Driving Customer Outcomes
MuleSoft's Approach to Driving Customer Outcomes MuleSoft's Approach to Driving Customer Outcomes
MuleSoft's Approach to Driving Customer Outcomes
 
Designing and building Mule applications
Designing and building Mule applicationsDesigning and building Mule applications
Designing and building Mule applications
 
Object Store
Object StoreObject Store
Object Store
 
Introducing Anypoint Exchange 2.0
Introducing Anypoint Exchange 2.0Introducing Anypoint Exchange 2.0
Introducing Anypoint Exchange 2.0
 
Troubleshooting Anypoint Platform
Troubleshooting Anypoint PlatformTroubleshooting Anypoint Platform
Troubleshooting Anypoint Platform
 
Relevancy in a Rapidly Changing World (Yvonne Wassenaar)
Relevancy in a Rapidly Changing World (Yvonne Wassenaar)Relevancy in a Rapidly Changing World (Yvonne Wassenaar)
Relevancy in a Rapidly Changing World (Yvonne Wassenaar)
 
Leveraging APIs and the Cloud to Transform Veteran Care (Steve Rushing)
Leveraging APIs and the Cloud to Transform Veteran Care (Steve Rushing)Leveraging APIs and the Cloud to Transform Veteran Care (Steve Rushing)
Leveraging APIs and the Cloud to Transform Veteran Care (Steve Rushing)
 
Role of Technology in the Evolution of P&C Insurance (Marcus Ryu)
Role of Technology in the Evolution of P&C Insurance (Marcus Ryu)Role of Technology in the Evolution of P&C Insurance (Marcus Ryu)
Role of Technology in the Evolution of P&C Insurance (Marcus Ryu)
 

Recently uploaded

Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfUnlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
Malak Abu Hammad
 
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of GermanyPresentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
innovationoecd
 
GraphSummit Singapore | Enhancing Changi Airport Group's Passenger Experience...
GraphSummit Singapore | Enhancing Changi Airport Group's Passenger Experience...GraphSummit Singapore | Enhancing Changi Airport Group's Passenger Experience...
GraphSummit Singapore | Enhancing Changi Airport Group's Passenger Experience...
Neo4j
 
Microsoft - Power Platform_G.Aspiotis.pdf
Microsoft - Power Platform_G.Aspiotis.pdfMicrosoft - Power Platform_G.Aspiotis.pdf
Microsoft - Power Platform_G.Aspiotis.pdf
Uni Systems S.M.S.A.
 
TrustArc Webinar - 2024 Global Privacy Survey
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc Webinar - 2024 Global Privacy Survey
TrustArc Webinar - 2024 Global Privacy Survey
TrustArc
 
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AI
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIEnchancing adoption of Open Source Libraries. A case study on Albumentations.AI
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AI
Vladimir Iglovikov, Ph.D.
 
20240605 QFM017 Machine Intelligence Reading List May 2024
20240605 QFM017 Machine Intelligence Reading List May 202420240605 QFM017 Machine Intelligence Reading List May 2024
20240605 QFM017 Machine Intelligence Reading List May 2024
Matthew Sinclair
 
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdf
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfObservability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdf
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdf
Paige Cruz
 
Building RAG with self-deployed Milvus vector database and Snowpark Container...
Building RAG with self-deployed Milvus vector database and Snowpark Container...Building RAG with self-deployed Milvus vector database and Snowpark Container...
Building RAG with self-deployed Milvus vector database and Snowpark Container...
Zilliz
 
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
名前 です男
 
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Albert Hoitingh
 
A tale of scale & speed: How the US Navy is enabling software delivery from l...
A tale of scale & speed: How the US Navy is enabling software delivery from l...A tale of scale & speed: How the US Navy is enabling software delivery from l...
A tale of scale & speed: How the US Navy is enabling software delivery from l...
sonjaschweigert1
 
Pushing the limits of ePRTC: 100ns holdover for 100 days
Pushing the limits of ePRTC: 100ns holdover for 100 daysPushing the limits of ePRTC: 100ns holdover for 100 days
Pushing the limits of ePRTC: 100ns holdover for 100 days
Adtran
 
Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !
KatiaHIMEUR1
 
Full-RAG: A modern architecture for hyper-personalization
Full-RAG: A modern architecture for hyper-personalizationFull-RAG: A modern architecture for hyper-personalization
Full-RAG: A modern architecture for hyper-personalization
Zilliz
 
20240607 QFM018 Elixir Reading List May 2024
20240607 QFM018 Elixir Reading List May 202420240607 QFM018 Elixir Reading List May 2024
20240607 QFM018 Elixir Reading List May 2024
Matthew Sinclair
 
Data structures and Algorithms in Python.pdf
Data structures and Algorithms in Python.pdfData structures and Algorithms in Python.pdf
Data structures and Algorithms in Python.pdf
TIPNGVN2
 
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...
Zilliz
 
Essentials of Automations: The Art of Triggers and Actions in FME
Essentials of Automations: The Art of Triggers and Actions in FMEEssentials of Automations: The Art of Triggers and Actions in FME
Essentials of Automations: The Art of Triggers and Actions in FME
Safe Software
 
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...
James Anderson
 

Recently uploaded (20)

Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfUnlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdf
 
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of GermanyPresentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
 
GraphSummit Singapore | Enhancing Changi Airport Group's Passenger Experience...
GraphSummit Singapore | Enhancing Changi Airport Group's Passenger Experience...GraphSummit Singapore | Enhancing Changi Airport Group's Passenger Experience...
GraphSummit Singapore | Enhancing Changi Airport Group's Passenger Experience...
 
Microsoft - Power Platform_G.Aspiotis.pdf
Microsoft - Power Platform_G.Aspiotis.pdfMicrosoft - Power Platform_G.Aspiotis.pdf
Microsoft - Power Platform_G.Aspiotis.pdf
 
TrustArc Webinar - 2024 Global Privacy Survey
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc Webinar - 2024 Global Privacy Survey
TrustArc Webinar - 2024 Global Privacy Survey
 
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AI
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIEnchancing adoption of Open Source Libraries. A case study on Albumentations.AI
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AI
 
20240605 QFM017 Machine Intelligence Reading List May 2024
20240605 QFM017 Machine Intelligence Reading List May 202420240605 QFM017 Machine Intelligence Reading List May 2024
20240605 QFM017 Machine Intelligence Reading List May 2024
 
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdf
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfObservability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdf
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdf
 
Building RAG with self-deployed Milvus vector database and Snowpark Container...
Building RAG with self-deployed Milvus vector database and Snowpark Container...Building RAG with self-deployed Milvus vector database and Snowpark Container...
Building RAG with self-deployed Milvus vector database and Snowpark Container...
 
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
 
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
 
A tale of scale & speed: How the US Navy is enabling software delivery from l...
A tale of scale & speed: How the US Navy is enabling software delivery from l...A tale of scale & speed: How the US Navy is enabling software delivery from l...
A tale of scale & speed: How the US Navy is enabling software delivery from l...
 
Pushing the limits of ePRTC: 100ns holdover for 100 days
Pushing the limits of ePRTC: 100ns holdover for 100 daysPushing the limits of ePRTC: 100ns holdover for 100 days
Pushing the limits of ePRTC: 100ns holdover for 100 days
 
Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !
 
Full-RAG: A modern architecture for hyper-personalization
Full-RAG: A modern architecture for hyper-personalizationFull-RAG: A modern architecture for hyper-personalization
Full-RAG: A modern architecture for hyper-personalization
 
20240607 QFM018 Elixir Reading List May 2024
20240607 QFM018 Elixir Reading List May 202420240607 QFM018 Elixir Reading List May 2024
20240607 QFM018 Elixir Reading List May 2024
 
Data structures and Algorithms in Python.pdf
Data structures and Algorithms in Python.pdfData structures and Algorithms in Python.pdf
Data structures and Algorithms in Python.pdf
 
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...
 
Essentials of Automations: The Art of Triggers and Actions in FME
Essentials of Automations: The Art of Triggers and Actions in FMEEssentials of Automations: The Art of Triggers and Actions in FME
Essentials of Automations: The Art of Triggers and Actions in FME
 
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...
 

Building Your API for Longevity

  • 1. Building Your API for Longevity by mike stowe l All contents Copyright © 2014, MuleSoft Inc.
  • 2. Disclaimer This talk is not about how to code your API, but rather to show you what steps and best practices you need to utilize to build a successful, long-lived API to the extent that we can in 45 minutes. l All contents Copyright © 2014, MuleSoft Inc.
  • 3. About Me • API Fanatic • Open Source Contributor • Author, Speaker, Consultant • 10+ years hacking Professional Code • Dev Relations Manager at MuleSoft l All contents Copyright © 2014, MuleSoft Inc.
  • 4. APIs are changing the world. l All contents Copyright © 2014, MuleSoft Inc.
  • 5. Over 13,000 PUBLIC APIs l All contents Copyright © 2014, MuleSoft Inc.
  • 6. l All contents Copyright © 2014, MuleSoft Inc.
  • 7. Today APIs are connecting… l All contents Copyright © 2014, MuleSoft Inc.
  • 8. PHONES l All contents Copyright © 2014, MuleSoft Inc.
  • 9. WATCHES l All contents Copyright © 2014, MuleSoft Inc.
  • 10. GLASSES l All contents Copyright © 2014, MuleSoft Inc.
  • 11. CARS l All contents Copyright © 2014, MuleSoft Inc.
  • 12. REFRIGERATORS l All contents Copyright © 2014, MuleSoft Inc.
  • 13. THERMOSTATS l All contents Copyright © 2014, MuleSoft Inc.
  • 14. l All contents Copyright © 2014, MuleSoft Inc. IN HOME ROBOTS
  • 15. AND MORE l All contents Copyright © 2014, MuleSoft Inc.
  • 16. THINK ABOUT THAT… l All contents Copyright © 2014, MuleSoft Inc.
  • 17. In order to work, the IoT requires that APIs remain persistent. l All contents Copyright © 2014, MuleSoft Inc.
  • 18. l All contents Copyright © 2014, MuleSoft Inc. +
  • 19. Versioning and making changes is expensive… l All contents Copyright © 2014, MuleSoft Inc.
  • 20. FOR EVERYONE. l All contents Copyright © 2014, MuleSoft Inc.
  • 21. Thankfully with 5 Simple Steps you can build an API that is designed to last. l All contents Copyright © 2014, MuleSoft Inc.
  • 22. They are: 1 – Go in with a long-term mindset 2 – Understand what you’re building 3 – Utilize Spec Driven Development 4 – Incorporate Best Practices 5 – Repeat steps 1-4 for all new features l All contents Copyright © 2014, MuleSoft Inc.
  • 23. Think Long-term: • Your API is a Contract • Versioning is not a solution • Understand you suck at design • You can pay a little now, or much more later • You need to think things through • Mind-set is everything l All contents Copyright © 2014, MuleSoft Inc.
  • 24. Your Users are Depending on You… Your API is a contract, it’s your word to your users. Users who are not only depending on a working API to integrate with your service, but in order to provide food for their families. l All contents Copyright 24 © 2014, MuleSoft Inc.
  • 25. This means you need to think through every aspect of your API before building it. l All contents Copyright © 2014, MuleSoft Inc.
  • 26. Thinking things through… • Who is your API for? • What type of API are you building? • How are you going to maintain your API? • How are you going to document your API? • How are you going to let users interact with your API? • How are you going to manage authentication, provisioning, throttling, and developer security? • How are you going to protect your servers against attacks, developer misuse, etc? • How are you going to manage support? l All contents Copyright 26 © 2014, MuleSoft Inc.
  • 27. Who Will Be Using Your API? • Who are your end users? - Current customers - Business partners - Third-party services • What actions do they need access to? - This means sitting down and talking to them! • How can you involve them in the design process? - Your users should be involved from Day One. l All contents Copyright 27 © 2014, MuleSoft Inc.
  • 28. What is the Purpose of Your API? • List out WHY you are making the API - Saying that you’re exposing your data to users is not good enough- explain HOW they will use it • Explain how your API will interact with existing services • List out the actions the API needs to be able to handle - Users: add, edit, reset password, delete, etc… - Messages: draft, send, retrieve, archive, etc… • Do only what is NECESSARY • DON’T get fancy. l All contents Copyright 28 © 2014, MuleSoft Inc.
  • 29. List Out What Your Users Need to be able to Do: l All contents Copyright 29 © 2014, MuleSoft Inc.
  • 30. What Type of API Are You Building? • Are you building a REST, partial REST, SOAP, or RPC based API? • Why are you building your API in that format? • What does that mean for development? • What does that mean for usability? • What does that mean for longevity? l All contents Copyright 30 © 2014, MuleSoft Inc.
  • 31. What Type of API Are You Building? l All contents Copyright 31 © 2014, MuleSoft Inc.
  • 32. Do You Understand the REST Constraints? • Client-Server • Stateless • Cacheable • Interface/ Uniform Contract • Layered System • Code on Demand (optional) l All contents Copyright 32 © 2014, MuleSoft Inc.
  • 33. Most APIs are NOT RESTful. l All contents Copyright © 2014, MuleSoft Inc.
  • 34. This is why it’s so important to understand the different types of APIs, why each type is different, and why you are choosing one over the other. l All contents Copyright © 2014, MuleSoft Inc.
  • 35. It also means building your API for beyond today… l All contents Copyright © 2014, MuleSoft Inc.
  • 36. ...people are fairly good at short-term design, and usually awful at long-term design.” “ l All contents Copyright 36 © 2014, MuleSoft Inc. -Dr. Roy Fielding
  • 37. Versioning is a necessary evil. l All contents Copyright © 2014, MuleSoft Inc.
  • 38. Problems with Versioning • Backwards incompatibilities • Multiple Services to Maintain • Multiple Systems to Support • Creates confusion among developers • Developer adoption is nearly impossible l All contents Copyright 38 © 2014, MuleSoft Inc.
  • 39. You Need to Version When: • Backwards incompatible platform changes • Your API is no longer extendable • Your spec is out dated (ie SOAP) l All contents Copyright 39 © 2014, MuleSoft Inc.
  • 40. But You Shouldn’t Version Just Because You: • Added new endpoints • Added additional data in response • Changed technologies (java toruby) • Changed your application’s services (code) l All contents Copyright 40 © 2014, MuleSoft Inc.
  • 41. Versioning does not excuse poor design. l All contents Copyright © 2014, MuleSoft Inc.
  • 42. And a poorly designed API will cost you far more in the long run, adding months to fix what could have been prevented in weeks. There are no shortcuts or quick fixes, you can either build your API the right way to begin with, or pay substantially for it in the long-run. l All contents Copyright © 2014, MuleSoft Inc.
  • 43. Use Spec Driven Development • Define your API before Coding • Use Design Patterns/ Code Reuse • Mock and get User Feedback • Make Necessary Changes • Start Coding – to the Spec • DO NOT DEVIATE! l All contents Copyright © 2014, MuleSoft Inc.
  • 44. Spec Driven Development means a hybrid between agile and waterfall methodologies. You should develop your spec iteratively, incorporating agile user testing. However, the actual development (coding) of your API should be static, driven by the spec with no deviation. l All contents Copyright © 2014, MuleSoft Inc.
  • 45. Disclaimer: Waterfall refers to the spec and changing the spec only! You should still use sprints for code development – just at this point the spec should not be changing. l All contents Copyright © 2014, MuleSoft Inc.
  • 46. Hybrid Approach Design Development Continuous, fluid, changeable Static… No turns l All contents Copyright 46 © 2014, MuleSoft Inc.
  • 47. The Agile Design Cycle l All contents Copyright 47 © 2014, MuleSoft Inc.
  • 48. The goal is that by utilizing agile user testing, carefully designing, and prototyping your API in an iterative state, that most design related issues have already been discovered and resolved. Allowing you to develop fearlessly. l All contents Copyright © 2014, MuleSoft Inc.
  • 49. The problem is up until now, designing and prototyping an API has been extremely costly. Requiring developers to create a mock API through extensive coding, and without any real constraints/ pattern reuse. l All contents Copyright © 2014, MuleSoft Inc.
  • 50. However, there are several new specs being driven by today’s industry leaders making it easier define your API: with tools to design, prototype, document, and allow user interaction. l All contents Copyright © 2014, MuleSoft Inc.
  • 51. Some of Today’s Specs: • RAML • IO Docs • Swagger • API Blueprint l All contents Copyright 51 © 2014, MuleSoft Inc.
  • 52. Using RAML You Can: • You can define your API in just a few lines of code • You can see what it would look like as you go • You can quickly prototype it for devs to try • You can quickly make tweaks/ changes • You can easily document your API • You can let developers try your API online • You can let developers interact with your and other APIs • Generate SDKs/ client libraries for your API (APIMatic.io) l All contents Copyright 52 © 2014, MuleSoft Inc.
  • 53. More Importantly… • You can use design patterns • You can reuse code (traits, resourceTypes) resourceTypes: -­‐ collection: description: Collection of available <<resourcePathName>> in Jukebox. get: description: Get a list of <<resourcePathName>>. responses: 200: body: application/json: example: | <<exampleCollection>> l All contents Copyright 53 © 2014, MuleSoft Inc.
  • 54. The RAML API Designer l All contents Copyright 54 © 2014, MuleSoft Inc.
  • 55. What Does RAML Look Like? #%RAML 0.8 title: World Music API baseUri: http://example.api.com/{version} version: v1 /playlists: get: responses: 200: body: application/json: example: | { “playlistID” : 1, “playlistName” : “My Awesome Playlist”, “genre” : “top40”, “songs” : 40 } l All contents Copyright 55 © 2014, MuleSoft Inc.
  • 56. Remember, your spec is not a one-and-done, rather it is the blueprint for your API. Anytime you do something to your API you should be modifying the spec and going through user testing before writing code. You should never have code that does something not defined by your spec. l All contents Copyright © 2014, MuleSoft Inc.
  • 57. Incorporate Best Practices: • Use Nouns • Use CRUD • Use Hypermedia (HATEOAS) • Use Accept/ Content-Type • Return Header Codes • Return Descriptive Error Messages l All contents Copyright © 2014, MuleSoft Inc.
  • 58. Use Nouns. l All contents Copyright © 2014, MuleSoft Inc.
  • 59. Use: /users Not: /createUser /getUser /deleteUser l All contents Copyright © 2014, MuleSoft Inc.
  • 60. Utilize CRUD. l All contents Copyright © 2014, MuleSoft Inc.
  • 61. Create (POST) Read (GET) Update (PUT/ l All contents Copyright © 2014, MuleSoft Inc. PATCH) Delete (DELETE)
  • 62. Use Hypermedia. l All contents Copyright © 2014, MuleSoft Inc. HATEOAS
  • 63. Most Popular Hypertext Link Specs • HAL • JSON-LD • JSON API • Siren l All contents Copyright 63 © 2014, MuleSoft Inc.
  • 64. { "data" : { "user": { "fname":"first", "lname":"last" } }, "_links" : { "edit": { "href" : "/api/user/id/1" }, "message": { "href" : "/api/message/id/1/lname/last" } } } l All contents Copyright © 2014, MuleSoft Inc. HAL
  • 65. Use Accept/ Content-Type Headers. l All contents Copyright © 2014, MuleSoft Inc.
  • 66. Use Accept/ Content-Type Headers Using headers gives you flexibility to support multiple types of formats from the same resource without worrying about breaking backwards compatibility. Most common: • application/json - wider language support • application/xml l All contents Copyright 66 © 2014, MuleSoft Inc.
  • 67. Use Response Codes. l All contents Copyright © 2014, MuleSoft Inc.
  • 68. • 200 – OK • 201 – Created • 304 – Not modified • 400 – Bad Request • 401 – Not Authorized • 403 – Forbidden • 404 – Page/ Resource Not Found • 405 – Method Not Allowed • 415 – Unsupported Media Type • 500 – Internal Server Error l All contents Copyright © 2014, MuleSoft Inc.
  • 69. Or if you’re feeling super creative… • 418 – I’m a Teapot… • 420 – Enhance Your Calm l All contents Copyright © 2014, MuleSoft Inc.
  • 70. Use Descriptive Error Messages. l All contents Copyright © 2014, MuleSoft Inc.
  • 71. The more information you provide, the easier it will be for developers to integrate your API without contacting Support. { 'exception' { 'code' : 'e3526', 'message' : 'Missing UserID', 'description' : 'A UserID is required to edit a user.', 'link' : 'http://docs.mysite.com/errors/e3526/' } } l All contents Copyright © 2014, MuleSoft Inc.
  • 72. Also be sure to keep your documentation up to date and simple enough for developers to quickly find and implement solutions to even the most complex problems. Poor documentation has been the death of many an API. l All contents Copyright © 2014, MuleSoft Inc.
  • 73. Finally, when adding new things to your API, be sure to: l All contents Copyright © 2014, MuleSoft Inc.
  • 74. Finally, when adding new things to your API, be sure to: 1 – Go in with a long-term mindset 2 – Understand what you’re building 3 – Utilize Spec Driven Development 4 – Incorporate Best Practices l All contents Copyright © 2014, MuleSoft Inc.
  • 75. It only takes ONE little thing to significantly reduce your API’s life span. Every action you make on your API must be carefully thought out and tested BEFORE being pushed to production. l All contents Copyright © 2014, MuleSoft Inc.
  • 76. Remember... l All contents Copyright © 2014, MuleSoft Inc.
  • 77. Building an API is easy. l All contents Copyright © 2014, MuleSoft Inc.
  • 78. Designing an API is hard. l All contents Copyright © 2014, MuleSoft Inc.
  • 79. l All contents Copyright © 2014, MuleSoft Inc. read more @ blogs.mulesoft.org
  • 80. l All contents Copyright © 2014, MuleSoft Inc. @MuleDev www.mulesoft.com