This document discusses the history and characteristics of various web API technologies, including SOAP, REST, OData, GraphQL, Falcor, and JSON API. It argues that while GraphQL follows REST architectural constraints like uniform interface and hypermedia, REST itself is not a standard. The best technology depends on the specific needs and requirements of each project and team.

1. If you know what I mean
GRAPHQL IS ACTUALLY REST

2. JAKUB RIEDL
Software Engineer @iflix
lead of GraphQL project

3. In we redefine television for a billion people

4. WHY DO WE NEED API?

5. WHY DO WE NEED API?
TO TRANSFER STATE BETWEEN BACKEND AND FRONTEND

6. 1999
SOAP
HISTORY OF WEB API TECHNOLOGIES
2000
REST
2007
OData
2015
GraphQL
Falcor
2013
JSON API

7. ● A protocol
● XML Based
● RPC methods
● Usually over HTTP or SMTP
SOAP Standard Object Access Protocol (1999)

8. SOAP Standard Object Access Protocol (1999)

9. ● Architectural style introduced by Roy Fielding in his PhD dissertation
● Most commonly uses JSON
● Centered around resources
● Usually over HTTP
REST Representational State Transfer (2000)

10. ● Client - Server
● Stateless
● Cacheable
● Layered System
● Uniform Interface
○ Identification of resources
○ Manipulation of resources through these representations
○ Self-descriptive messages
○ Hypermedia as the engine of application state
REST ARCHITECTURAL CONSTRAINTS

11. REST Representational State Transfer (2000)

12. RESTful One endpoint per resource
Users CommentsPosts
Browser AndroidiOS
- Server centric
Pros
- Flexible
- Easy to implement
- Decoupled features
Cons
- Coupled BE w/ FE
- Lots of roundtrips
- Over-fetching
- Inconsistent
- Complex clients

13. - Client centric (ish)
Pros
- One round trip
- Exactly what you need
Cons
- Inflexible
- Inconsistent
- Expensive
- Slow to iterate
REST-ish One endpoint per view (Backend for frontend)
View A (web)
View C
(mobile)
View B (web)
Browser AndroidiOS

14. RESTful One gateway with resources
Users CommentsPosts
Browser AndroidiOS
Standardized API Layer
Pros
- Flexible
- Decoupled
- No extra roundtrips
- Consistent
- Easier for clients
Cons
- Single point of failure
- Perf overhead

15. STANDARDIZATION
1960 2016

16. Users CommentsPosts
Browser AndroidiOS
Requirements
- Client centric
- Minimize roundtrips
- Reduce data transfer
- Flexible
- Decoupled
- Consistent
?

17. Users CommentsPosts
Browser AndroidiOS
Real Requirements
- Fast to iterate
- Time to market
- Developer experience
- Tooling
- Docs
?

18. ● $select: choose which fields you want
● $expand: fetch related resources
● $top + $skip: pagination
● $filter (eq, lt, startswith, ...): server-side filtering
● $metadata: introspection + discovery
ODATA “The best way how to REST” *
* says Microsoft

19. ODATATM

20. ODATATM

21. ODATATM
£9.59
per month

22. ● All data modelled as a JSON object with references
● All values resolve asynchronously
● “Routes” determine how data is fetched
● Data is treated as graph
● Easy to learn & use
● No type system, no arguments
● Limited tooling
FALCOR

23. FALCOR

24. ● “The clean way”
● Leverages features of HTTP (caching, content negotiation, ...)
● Not typed by default
● Limited tooling
JSON API

25. JSON API

26. ● Easy-to-use query language
● Strongly typed = consistent
● Very popular last months
● Great tooling
● Ready made clients
● Great developer experience
● Complexity comes with scale
GRAPHQL

27. GRAPHQL
developer.iflix.com
real world example

28. ● Client - Server
● Stateless
● Cacheable
● Layered System
● Uniform Interface
○ Identification of resources
○ Manipulation of resources through these representations
○ Self-descriptive messages
○ Hypermedia as the engine of application state
IS GRAPHQL RESTful?

29. ● Every object/resource has a globally unique id
● Every resource can be retrieved given its id
NODE INTERFACE

30. NODE INTERFACE

31. Uniform interface
● Identification of resources
● Manipulation of resources through these representations
● Self-descriptive messages
● Hypermedia as the engine of application state
GRAPHQL + NODE INTERFACE == RESTful

32. WHAT TO CHOOSE?

33. WHAT TO CHOOSE?
IT DEPENDS.

34. SUMMARY

35. SUMMARY
REST IS NOT A STANDARD

36. SUMMARY
REST IS NOT A STANDARD
FOCUS ON YOUR NEEDS

37. THANKS TO
JONAS HELFER: GRAPHQL - EVOLUTION OR REVOLUTION?

38. 3
8
WE ARE HIRING
.com

39. jakubriedl.com
@jakubriedl
jakubriedl
jakubriedl
GET IN TOUCH