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.
About me 
Łukasz Wierzbicki 
• +10 years of 
professional 
experience 
• software engineer, 
architect, manager
Motivation 
• lots of ideas how to mark versions 
• lots of theory 
• ...little practise 
• any actual solution?
Why do we need 
versioning? 
• new fields in particular 
resource 
• we don't need some 
fields any longer 
• we're startu...
Assumptions 
• business logic returns model 
• controllers return views 
• object-json/xml/? mapping done 
transparently
Possibilities 
• several versions of model, 
• model as a “view” 
• one object mapper 
cons: a lot of code, DAOs and servi...
Possibilities, flow 
no 1 
Dao 1 
Dao 2 
Service 1 Backend 1 
Service 2 
Backend 2 
Model 1 
Model 2 
Controller 1 
Contro...
Possibilities 
• one model 
• converters 
• several versions of view objects 
• one object mapper 
no 2
Possibilities, flow 
no 2 
Backend 1 
Dao Service 
Backend 2 
Converter 1 
Converter 2 
cons: still a lot of boilerplate c...
Possibilities 
no 3 
• one model 
• one view/proxy factory 
• several versions of dynamic proxies 
• one object mapper
public class Address { 
private final String street; 
private final String city; 
public Address(String street, String cit...
Possibilities, flow 
Model 
no 3 
Dao Service 
Backend 1 
Controller 1 
cons: some magic to write/handle 
pros: even less ...
Possibilities 
no 4 
• one model 
• view factory having list of properties 
• map as a view 
• one object mapper
Possibilities, flow 
no 4 
Dao Service 
Backend 1 
Backend 2 
View 
Factory 1 
Response 
Version Router Request 
Response ...
Possibilities 
• lots of combinations 
• i.e. one view, one object mapper 
public class AddressView { 
@Version("1", "2", ...
Our choice - no 4 
• because it is easy to use 
• because of less boilerplate code, 
and we don't have time to make / 
mai...
How? 
• converters get properties values and put them to maps 
• include list: “length”, user.role”, “user.id”, “user.name...
Our api… foreword 
• REST but not RESTful/ 
HATEOAS 
• Just Http GETs and POSTs 
• Verbs in paths, i.e.: create, 
update, ...
Thank You!
Upcoming SlideShare
Loading in …5
×

JDD2014: REST API versioning practice: from header to model - Łukasz Wierzbicki

389 views

Published on

Why REST API should be backward compatible and why it is hard to achieve. The talk will be about that and other problems we have encountered in Kontakt.io when building platform for worldwide services.

Published in: Services
  • Be the first to comment

  • Be the first to like this

JDD2014: REST API versioning practice: from header to model - Łukasz Wierzbicki

  1. 1. About me Łukasz Wierzbicki • +10 years of professional experience • software engineer, architect, manager
  2. 2. Motivation • lots of ideas how to mark versions • lots of theory • ...little practise • any actual solution?
  3. 3. Why do we need versioning? • new fields in particular resource • we don't need some fields any longer • we're startup • people are already using our API Why, why, why?
  4. 4. Assumptions • business logic returns model • controllers return views • object-json/xml/? mapping done transparently
  5. 5. Possibilities • several versions of model, • model as a “view” • one object mapper cons: a lot of code, DAOs and services pros: don't see any no 1
  6. 6. Possibilities, flow no 1 Dao 1 Dao 2 Service 1 Backend 1 Service 2 Backend 2 Model 1 Model 2 Controller 1 Controller 2 Response Response cons: a lot of code, DAOs and services pros: don't see any Version Router Request
  7. 7. Possibilities • one model • converters • several versions of view objects • one object mapper no 2
  8. 8. Possibilities, flow no 2 Backend 1 Dao Service Backend 2 Converter 1 Converter 2 cons: still a lot of boilerplate code pros: less code than previously Response Version Router Request Response Model View 1 View 2 Controller 1 Controller 2 Model
  9. 9. Possibilities no 3 • one model • one view/proxy factory • several versions of dynamic proxies • one object mapper
  10. 10. public class Address { private final String street; private final String city; public Address(String street, String city) { super(); this.street = street; this.city = city; } public String getStreet() { return street; } public String getCity() { return city; } } @View public interface AddressV1 { String getStreet(); @Property("city") String getTown(); @Provider(Public.class ) Boolean getPublic(); class Public implements Provider<Address> { @Override public Object get(Address source) { return true; } } } Some code...
  11. 11. Possibilities, flow Model no 3 Dao Service Backend 1 Controller 1 cons: some magic to write/handle pros: even less code to handle Response Version Router Request Response View 2 Controller 2 Proxy Factory Backend 2 View.class View 1
  12. 12. Possibilities no 4 • one model • view factory having list of properties • map as a view • one object mapper
  13. 13. Possibilities, flow no 4 Dao Service Backend 1 Backend 2 View Factory 1 Response Version Router Request Response Map Map Controller 1 Controller 2 View Factory 2 cons: some magic to write/handle pros: small amount of code, partial resources
  14. 14. Possibilities • lots of combinations • i.e. one view, one object mapper public class AddressView { @Version("1", "2", "3") private String street; @Version1 @Version3("town") private String city; } no ...
  15. 15. Our choice - no 4 • because it is easy to use • because of less boilerplate code, and we don't have time to make / maintain it • because we wanted to have “partial resources”
  16. 16. How? • converters get properties values and put them to maps • include list: “length”, user.role”, “user.id”, “user.name” • exclude list - great for small changes • “generated fields” - when hotfix needed • “mappings” - “name from model” -> “name in json”
  17. 17. Our api… foreword • REST but not RESTful/ HATEOAS • Just Http GETs and POSTs • Verbs in paths, i.e.: create, update, assign
  18. 18. Thank You!

×