When RESTful may be considered harmful

When RESTful may be considered harmful

Copyright Push Technology 2015

Ross Garrett

@gssor

We make the Internet work for the mobile-obsessed, app-loving, everything-connected world.

4


•  We’re defining the market for must-have “Internet Messaging” technology

•  Our software gives business critical apps a performance edge

•  It’s delivered in the way that works for you

•  Founded 2006; recognized expertise in delivering data at scale and speed

•  European HQ in London | Americas HQ in San Jose, CA Selected Customers

Who we are

5

Selected Partners

RESTful may be harmful, eh?


Yeah…

Here are the Top 10 reasons why RESTful may be considered

harmful

You won’t believe number 7!!

8


What do we mean by RESTful?

9

Copyright Push Technology 2015 10


Level 2 - HTTP Verbs

http://martinfowler.com/articles/richardsonMaturityModel.html


An example Level 2 API

http://blog.sgo.to/2014/04/what-your-api-would-look-like-as-webpage.html


Looking at this as a Web Page



Looking at this as a Web Page



Most Web APIs haven’t reached Level 3 – The Glory of REST

15


What constitutes “harmful”?

•  Poor end-user experience •  Insufficient scaling capacity

•  Inappropriate implementation / usage


Poor User Experience

• This usually means slow / unreliable apps

• Often caused by the network

17


#1 Data redundancy

{uid:1234567890,title:“Something”,db_key:“some_thing_item”,modified_date:“13-06-1991”,…}


#1 Data redundancy

{uid:1234567890,title:“Somethingelse”,db_key:“some_thing_item”,modified_date:“06-08-2015”,…}

It’s like the Internet is running with Debug turned on


Insufficient scaling capability

• Growing from 1000 users to 1,000,000 users

• Should we simply add CPUs, NICs, etc?

20


#2 Data delivery

Your clients


#2 Data delivery

•  How many requests do you service for data that hasn’t changed?

•  Guess what? HTTP 304 is a thing

•  Everything has a cost; only pay for what you need


Inappropriate Implementation

•  REST APIs often mimic backend systems & operations

•  If one system needs to notify another about an event - do they really need to exist at the same time?

23


#3 Coupling

24


#3 Coupling

•  Message-driven distributed architectures prove to be much more robust and fault-tolerant.

•  Producers and consumers are truly independent.

•  Scalability is easier to achieve, and we can distribute messages to multiple systems at a time.



The Internet…

•  Unknown, uncontrolled resource

•  It will let you down –  Insufficient bandwidth –  Inconsistent bandwidth –  High latency –  Loss of connectivity on a regular basis

•  Be sympathetic to realities of the network


The (mobile) Internet…

•  HTTP & TCP slow-start are usually not a good match for constantly dropped connections

•  Network interface kills battery

•  Large responses + periodic polling = bad


Solutions?

•  Avoid polling!

•  Avoid redundancies

•  Avoid multiple concurrent HTTP requests


Think Reactive

30

http://www.reactivemanifesto.org


The right fit

•  REST solves particular problems for a particular environment

•  Reactive apps almost demand streaming pub/sub messaging –  Websockets!

•  Conceptual simplicity != best performance


There is no “one size fits all” approach, think strategically and critically about your architecture

choices

32

Copyright Push Technology 2015 33

Thanks!

Subscribe to our blog

Follow us on Twitter

Check out our whitepapers

@reappt

@push_technology

@gssor

When RESTful may be considered harmful

Software