Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

REST to the Future

2,868 views

Published on

The API space is evolving, and what we know about REST is constantly being challenged, especially by the explosion of Microservices. So what does the future look like, and how can APIs become even more flexible and efficient. In this "preview of the future" we'll talk about some ideas. #NotProductionReady

Published in: Software

REST to the Future

  1. 1. l All contents Copyright © 2014, MuleSoft Inc. REST: to the future By @mikegstowe
  2. 2. l All contents Copyright © 2014, MuleSoft Inc. We have a problem…
  3. 3. l All contents Copyright © 2014, MuleSoft Inc. Microservices
  4. 4. l All contents Copyright © 2014, MuleSoft Inc.4 No Longer a “Big Enterprise” Problem mainframe FTP databases legacy ESB SaaS apps biz apps web service custom app
  5. 5. l All contents Copyright © 2014, MuleSoft Inc.5 System APIs (legacy modernization, connectivity to SaaS apps, web services & Restful APIs) Requires Multiple APIs Working Together Databases Legacy ESB Web service Mainframe FTPSaaS apps Biz apps Process APIs (orchestration, composable APIs) Experience APIs (purposeful APIs for apps)
  6. 6. l All contents Copyright © 2014, MuleSoft Inc. Content Negotiation
  7. 7. l All contents Copyright © 2014, MuleSoft Inc.7 Internet of Lots and Lots of Things As technology is changing, APIs need to be flexible enough to keep up with ever changing and new demands
  8. 8. l All contents Copyright © 2014, MuleSoft Inc.8 Most APIs are built for a single content type, without much thought given to the underlying data model. Your Users are Depending on You…
  9. 9. l All contents Copyright © 2014, MuleSoft Inc.9 The first focus should be the model of your data, not the format. Your Users are Depending on You…
  10. 10. l All contents Copyright © 2014, MuleSoft Inc.10 RAML 1.0 RAML 1.0 suggests a shift from manually writing single format schemas (XML, JSON, etc) to creating models that can be tied together and used both by software and exported as schemas.
  11. 11. l All contents Copyright © 2014, MuleSoft Inc.11 Why Models? I’m glad you asked…
  12. 12. l All contents Copyright © 2014, MuleSoft Inc. Faster, More Dynamic Calls
  13. 13. l All contents Copyright © 2014, MuleSoft Inc. API Chaining?
  14. 14. l All contents Copyright © 2014, MuleSoft Inc.14 API Chaining would allow for multiple calls to be made from a singular request – like Sprites but for APIs. API Chaining = Fewer Calls
  15. 15. l All contents Copyright © 2014, MuleSoft Inc.15 API Chaining?
  16. 16. l All contents Copyright © 2014, MuleSoft Inc.16 The problem here is that we are still relying on hard coded resources… and tightly coupling the user’s experience to our current API structure. The Catch
  17. 17. l All contents Copyright © 2014, MuleSoft Inc. Query Languages
  18. 18. l All contents Copyright © 2014, MuleSoft Inc.18 Models allow implementations of query languages similar to GraphQL Custom Data Structures based on Models
  19. 19. l All contents Copyright © 2014, MuleSoft Inc.19 However, GraphQL changes our understanding of REST… Not an Easy Implementation
  20. 20. l All contents Copyright © 2014, MuleSoft Inc.20 GraphQL also requires knowing the data structure and tightly couples everything to functions and your models. Also, Tightly Coupled L
  21. 21. l All contents Copyright © 2014, MuleSoft Inc. Hypermedia!!!
  22. 22. l All contents Copyright © 2014, MuleSoft Inc.22 Hypermedia is one of the most under-utilized aspects of REST. It’s treated as a commodity rather than the engine of state that it is. Hypermedia IS the Future of REST
  23. 23. l All contents Copyright © 2014, MuleSoft Inc.23 Hypermedia is used to describe resources, but CAN be used to describe possibilities. Hypermedia IS the Future of REST
  24. 24. l All contents Copyright © 2014, MuleSoft Inc.24 HAL and JSON API are GREAT hypermedia specs. But they are also very limited in scope. New spec such as Siren and CPHL work to expand how hypermedia is used, and how resources are represented. Off to a Good Start But…
  25. 25. l All contents Copyright © 2014, MuleSoft Inc.25 Siren also highlights the class, entities, actions, fields, and links. Off to a Good Start But…
  26. 26. l All contents Copyright © 2014, MuleSoft Inc.26 CPHL extends HAL, but brings in link expiration, methods, formats, decoupled doc links, code on demand, and reserved names. Off to a Good Start But…
  27. 27. l All contents Copyright © 2014, MuleSoft Inc.27 CPHL Example (extending HAL)
  28. 28. l All contents Copyright © 2014, MuleSoft Inc.28 API Chaining + CPHL
  29. 29. l All contents Copyright © 2014, MuleSoft Inc.29 Hypermedia can even declare models or pull in declarations from RAML, or schemas from Swagger. Hypermedia IS the Future of REST
  30. 30. l All contents Copyright © 2014, MuleSoft Inc.30 Disclaimer: I’m not saying to use CPHL or Siren – but I am saying we need to start investing more heavily in hypermedia, and weigh how we are utilizing it. Hypermedia IS the Future of REST
  31. 31. l All contents Copyright © 2014, MuleSoft Inc. Let’s start looking at REST another way…
  32. 32. l All contents Copyright © 2014, MuleSoft Inc.32 Richardson’s Model is a GREAT Start…
  33. 33. l All contents Copyright © 2014, MuleSoft Inc.33 But we’re still not tapping into the power of REST!!! Level 0: Your API is Actually RESTful Level 1: Your Links Mean Something Level 2: Advanced Hypermedia Level 3: Code on Demand
  34. 34. l All contents Copyright © 2014, MuleSoft Inc. Obligatory Quote
  35. 35. l All contents Copyright © 2014, MuleSoft Inc. ...people are fairly good at short-term design, and usually awful at long-term design.” “ -Dr. Roy Fielding
  36. 36. l All contents Copyright © 2014, MuleSoft Inc. Final Thought…
  37. 37. l All contents Copyright © 2014, MuleSoft Inc. If you always do what you’ve always done, you’ll always get what you’ve always got.” “ -Henry Ford
  38. 38. l All contents Copyright © 2014, MuleSoft Inc. @MuleDev mulesoft.com/restbook

×