raml for tech writers

30
l All contents Copyright © 2014, MuleSoft Inc. Spec Driven Development & Documentation by mike stowe

Upload: michael-stowe

Post on 16-Apr-2017

1.731 views

Category:

Internet


0 download

TRANSCRIPT

l All contents Copyright © 2014, MuleSoft Inc.

Spec Driven Development & Documentation

by mike stowe

l All contents Copyright © 2014, MuleSoft Inc.

• API Fanatic

• Open Source Contributor

• Author, Speaker, Consultant

• 10+ years hacking Professional Code

• Dev Relations Manager at MuleSoft

About Me

Follow me on Twitter: @mikegstowe

l All contents Copyright © 2014, MuleSoft Inc.

More importantly, I’ve been responsible

for creating, documenting, and supporting

APIs. And I can tell you – all of these are

TOUGH!

About Me

Follow me on Twitter: @mikegstowe

l All contents Copyright © 2014, MuleSoft Inc.

But let me ask you…

l All contents Copyright © 2014, MuleSoft Inc.

What are the Pain Points with:•  Building APIs

•  Documenting APIs

•  Supporting APIs

l All contents Copyright © 2014, MuleSoft Inc.

My #1 Problems:•  APIs are not designed for the users

•  Doc Teams get left out of the loop

•  No such thing as easy to debug code

l All contents Copyright © 2014, MuleSoft Inc.

My #1 Problems:•  APIs are not designed for the users

•  Doc Teams get left out of the loop

•  No such thing as easy to debug code

l All contents Copyright © 2014, MuleSoft Inc.

We could simplify the process, and make it

more efficient for everyone? What if we

could actually do even more… with less

work?

But What If…

l All contents Copyright © 2014, MuleSoft Inc.

With RAML and Spec Driven Development

we can!!!

Spec Driven Development

l All contents Copyright © 2014, MuleSoft Inc.

• 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!

Use Spec Driven Development

l All contents Copyright © 2014, MuleSoft Inc.

Spec Driven Development means a hybrid between agile and contract 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.

It also means bringing developers, technical writers, and even support together in the design cycle.

l All contents Copyright © 2014, MuleSoft Inc. 13

Hybrid Approach

Design Development

Continuous, fluid, changeable Static… No turns

l All contents Copyright © 2014, MuleSoft Inc. 14

The Agile Design Cycle

l All contents Copyright © 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.

And everyone knows what is going into the new API design, and knows that it has been tested to ensure usability and readability!

l All contents Copyright © 2014, MuleSoft Inc. 17

•  RAML

•  IO Docs

•  Swagger

•  API Blueprint

Some of Today’s Specs:

l All contents Copyright © 2014, MuleSoft Inc. 18

•  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)

Using RAML You Can:

l All contents Copyright © 2014, MuleSoft Inc. 19

•  You can use design patterns

•  You can reuse code (traits, resourceTypes)

More Importantly…

resourceTypes:-collection:description:Collectionofavailable<<resourcePathName>>inJukebox.get:description:Getalistof<<resourcePathName>>.responses:200:body:application/json:example:|<<exampleCollection>>

l All contents Copyright © 2014, MuleSoft Inc. 20

The RAML API Designer

l All contents Copyright © 2014, MuleSoft Inc. 21

What Does RAML Look Like?

#%RAML0.8title:WorldMusicAPIbaseUri:http://example.api.com/{version}version:v1/playlists:get:responses:200:body:application/json:example:|{“playlistID”:1,“playlistName”:“MyAwesomePlaylist”,“genre”:“top40”,“songs”:40}

l All contents Copyright © 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.

And because the spec is the source of truth – it can also be used for:- Documentation

- Interactive Tools

- SDK Generation

- Support

- & More!

l All contents Copyright © 2014, MuleSoft Inc.

But wait?! Does this replace technical writers???

l All contents Copyright © 2014, MuleSoft Inc.

Absolutely NOT

l All contents Copyright © 2014, MuleSoft Inc.

But it does replace “rework” and enables you to offer your users even more!

l All contents Copyright © 2014, MuleSoft Inc.

OK – enough of that. Let’s see how to actually do this stuff!

l All contents Copyright © 2014, MuleSoft Inc.

Cool huh? How about some real world examples?

l All contents Copyright © 2014, MuleSoft Inc.

“I’ve never come across all this in my previous TechWriter life, but noticed very soon that our inhouse documentation tool compared with simply editing markdown and raml files enriches my knowledge and makes my work far easier.”

-Birgit, e.Pages Dev Blog

l All contents Copyright © 2014, MuleSoft Inc.

Get the Book

http://mulesoft.com/restbook