RAML - APIs By Design
Upcoming SlideShare
Loading in...5
×
 

RAML - APIs By Design

on

  • 1,653 views

My talk (first given at HTML5 Dev Conference October 2013) about API design and RAML. See http://raml.org for more info.

My talk (first given at HTML5 Dev Conference October 2013) about API design and RAML. See http://raml.org for more info.

Statistics

Views

Total Views
1,653
Views on SlideShare
1,649
Embed Views
4

Actions

Likes
4
Downloads
39
Comments
0

1 Embed 4

https://twitter.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    RAML - APIs By Design RAML - APIs By Design Presentation Transcript

    • RAML – APIs By Design #RAML Uri Sarid CTO, MuleSoft @MuleSoft @usarid
    • APIs: The Cat's Meow
    • Ultimate Buzz for Creatively-lazy Developers build on someone else's work… who's? 14000 12000 open APIs 10000 8000 6000 4000 2000 0 2005 2006 2007 2008 2009 2010 2011 2012 Source: 2013
    • Modularity, Encapsulation, Specialization yes, even Service-Oriented Architecture!  eCommerce  products  shopping cart  checkout  billing  shipping  social  graph  posting  geolocation  city data  weather  attractions  businesses  collaboration  documents  notifications  forums  analytics  traffic  logs  NLP  sales  marketing  demographics  SFA  social
    • The API Economy Is Big and It's Now >13,000 Open APIs Enterprise APIs 1,000,000s
    • APIs and me
    • My Experience: consumer portal utility back-office software
    • The API Contract Is Critical • tells consumer devs what they'll get • tells implementer devs what to deliver • enables parallel development • ensures they'll meet in the end
    • My Experience: Barnes & Noble / the layer cake of APIs Don't expose dirty laundry  users products orders  invoices
    • At MuleSoft connectivity
    • The traditional enterprise sits comfortably behind the firewall Packaged apps Custom apps The Traditional Enterprise Databases
    • Welcome to the New Enterprise SaaS Social Cloud platforms Mobility and Devices Customers / Partners / Suppliers Packaged apps Custom apps The New Enterprise Databases
    • Connect backend SaaS Social Cloud platforms Mobility and Devices Customers / Partners / Suppliers Packaged apps Custom apps The New Enterprise Databases
    • Backend to SaaS SaaS Social Cloud platforms Mobility and Devices Customers / Partners / Suppliers Packaged apps Custom apps The New Enterprise Databases
    • Everything needs to connect SaaS Social Cloud platforms Mobility and Devices Customers / Partners / Suppliers Packaged apps Custom apps The New Enterprise Databases
    • The Anypoint Platform: integration on-premises and cloud SaaS Cloud platforms Social Anypoint Platform Mobility and Devices Customers / Partners / Suppliers Mule Studio Anypoint Connectors Anypoint DataMapper Enterprise Mgmt DataSense Packaged apps Business Insight Custom apps Big Databases / Big Files
    • The Anypoint Platform: integration on-premises and cloud 1,000s 100s SaaS 1,000,000s Cloud platforms 100,000s Social 1,000,000,000s Anypoint Platform Mobility and Devices Customers / Partners / Suppliers Mule Studio Anypoint Connectors Anypoint DataMapper Enterprise Mgmt DataSense Packaged apps Business Insight Custom apps Big Databases / Big Files
    • The Anypoint Platform for APIs SaaS Cloud platforms Social Anypoint Platform Design/Dev Portal API Manager APIkit Anypoint Connectors Mobility and Devices API Gateway Studio Customers / Partners / Suppliers Anypoint DataMapper Business Insight Enterprise Mgmt DataSense Packaged apps Custom apps Big Databases / Big Files
    • An Opinionated Approach to API Success
    • The Key to API Success? how? • • • • design for them iterate quickly model cleanly and consistently engage
    • Design For Your Users UI  UX Capture Feedback API  APX
    • Focus on the Interface: The Contract  where consumers touch you  your front door, your lobby, your façade  how you want to be seen; your brand  versioned more carefully than code  better interfaces  better code  an organizing principle; alignment forcing function  the ultimate testing surface
    • What kind of interface do we want? 1. Describe APIs simply and clearly 2. Design APIs easily and soundly 3. Engage users in compelling ways
    • Practically-RESTful APIs • • • • • • nouns: resources, described by URI paths verbs: HTTP methods metadata: HTTP headers responses: HTTP status codes representations: appropriate media types in the body use hypermedia – not necessarily, not yet
    • What Do People Do Today?
    • WADL
    • Reverb Swagger
    • Mashery IOdocs
    • Google Discovery Docs
    • Apiary Blueprint
    • Verdict: manifest structure capture patterns humanly writeable let's try harder…
    • Start From Scratch? Really???
    • No Need to Start From Scratch! • • • • • • • well-known superset of JSON optimized for human readability great for hierarchies cruft-free broad tooling base extensible-ish broad tooling base
    • Introducing: RAML RESTful API Modeling Language A new open spec for RESTful APIs that's as clean and as structured as REST itself the RAML Workgroup: raml.org
    • RAML: How Clean? How Structured? Take what you would have typed yourself… /users: get: description: post: description: /users/{userId}: get: description: put: description: delete: description: Get a collection of users Create a new user in the collection Get a single user Update a single user Delete a single user
    • RAML: How Clean? How Structured?
    • RAML: How Clean? How Structured?
    • RAML: How Clean? How Structured? resource type schema trait
    • Covers Full HTTP optional version in baseUri template URIs query parameters headers (on request and response) response per status code example (and schema) per media type
    • Patterns: Resource Types externalizable inheritance pull in traits parametrize
    • Patterns: Method-level traits mix-ins
    • Patterns: body schemas XML schema JSON schema or just use good ol' form data: examples
    • RAML for Real-Time APX Design
    • raml.org
    • What's next?  open-source tooling; host it too (e.g. on APIhub)  growing library of API specs in RAML (e.g. on APIhub)  converters  client generators  server frameworks (e.g. MuleSoft APIkit; node.js)  testing frameworks  mocking services (e.g. on APIhub)  <insert your ideas here>  evolve RAML spec (RAML workgroup)
    • One More Thing…