1. 1
#buildtogether
RESTful applications and Angular: The why and how
Author : Maikel Mardjan
Date : 24 February 2016
© 2016 Jexia Company
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

2. 2
Whoami?
Maikel Mardjan:
More than 20 years experience within IT
(System) Development. Worked as IT
Architect, Integrator, SW Developer. Now
working as developer for Jexia.com to
create the best developer tools around.
Struggled but won serious integration fights
using CORBA, RPCs, SOA, WSDLs.
https://nl.linkedin.com/in/maikelmardjan
@maikelmardjan
Questions? Please contact me!

3. 3
About this talk

4. 4
Agenda:REST: What, Why, How?
 Essence of REST
 How does REST work?
 Designing RESTful APIs
 Advantages and Disadvantages of REST
 Tools to work with REST
 Summary

5. 5
Why REST?
Defining, creating and managing application integration through APIs is
(was) hard!
Our needs / challenges / opportunities today:
Currently almost all new released software systems contains REST interfaces for
usage and/or control
SOAP
integration

6. 6
Why REST?
Defining, creating and managing application integration through APIs is (was) hard!
Our needs today:
● We need a simpler why to connect to (different) Cloud based services. SOAP and
WSDL-based interfaces were not that simple.
● We have a large range of devices of different vendors to integrate with (data)
backends (phones, watches, smartTVs, Navigation devices, etc).
● All large software cooperations (Google, Yahoo and Microsoft etc) have deprecated
SOAP and WSDL-based interfaces in favor of REST services to expose their services.
RESTful interfacing is easier, simpler and encourage information usage and sharing!
Currently almost all new released software systems contains REST interfaces for usage
and/or control.

7. 7
Why REST? (2)
Almost all large services today allow interacting/integration
by the use of RESTful APIs. Some examples:

8. 8
REST: So what is it really all about?
Representational State Transfer (REST):
 Architecture style for designing and implementing
networked applications.
 Lightweight alternative to mechanisms like RPC (Remote
Procedure Calls) and SOAP Web Services.
 REST is based on the HTTP specification.
Despite being simple, REST is not limited in usage!

9. 9
The REST standard?
By default REST is not a "standard"!
Do we need a standard for REST?

10. 10
The REST standard? (2)
By default REST is not a "standard"!
The current leading initiative to standardize REST
descriptions is currently a project from the Linux
Foundation organization (See https://openapis.org/ )

11. 11
Basic REST elements
Data element : pizzaHawaii
Resource : pizza, book, user, ticket etc
Resource identifier : URI , URN ( /pizzatype/34)
Data representation : JSON, txt, htmlt, XML, YAML etc
Metadata : content type, last-modified time
REST
(HTTP based integration)Verbs (GET,
POST, PUT, etc)
Representations
(Json, XML, etc)
Nouns (Resources) /order/pizza/45

12. 12
Working of REST (3)
Method RFC Description
GET Transfer a current representation of the target resource.
HEAD Same as GET, but only transfer the status line and header
section.
POST Perform resource-specific processing on the request payload.
PUT Replace all current representations of the target resource with
the request payload.
DELETE Remove all current representations of the target resource.
CONNECT Establish a tunnel to the server identified by the target resource.
OPTIONS Describe the communication options for the target resource.
TRACE Perform a message loop-back test along the path to the target
resource.
Good REST services should use the HTTP methods correctly. This means as defined
by RFC 7231.

13. 13
Working of REST

14. 14
Sample mockup
A simple task application with RESTful interfaces:
 GET /tasks – display all tasks
 POST /tasks – Create a new task
 GET /tasks/{id} display a task with id
 PUT /tasks/{id} – Update a task with id
 DELETE /tasks/{id} – Delete a tasks with id
When using REST calls to your data you can often make use of
data query options. These can be used to find, filter and sort the
output from your dataset.

15. 15
Designing RESTful APIs
Designing RESTful APIs is easy:
● To create a resource on the server, use POST.
● To retrieve a resource, use GET.
● To change the state of a resource or to update it, use PUT.
● To remove or delete a resource, use DELETE.

16. 16
Designing RESTful APIs (2)
REST interfaces are defined through the URL or URI:

17. 17
Designing RESTful APIs
Some simple design guidelines:
● Queries should not return an overload of data. If needed, provide a
paging mechanism.
● Even though the REST response can be anything, make sure it's well
documented (and do not change the output format since it will break
existing clients).
● GET access requests should never cause a state change.
● All communication is done by representation (e.g. XML/JSON). By
default JSON is the preferred representation to use.
● Be Stateless. Stateless ( Each request from any client contains all the
information. So all HTTP methods like caching and load-balance can be
used).

18. 18
Business Advantages when using REST?
Why should you (again) use something new?
What is the business value for you?
Why should you use RESTful services?

19. 19
Advantages of REST
● REST is 'light weight'. (Easy to develop, test, etc)
● Network and security friendly (e.g. firewalls, caching,
stateless, configuration, IDPS possible, no confusion on
wire-protocol)
● Human readable results since basic HTTP-based methods
are used with JSON. (when you choose to use json, why
not?)
● No hard coupling between client-server. Create your RESTful
client in the programming language you want!

20. 20
Disadvantages of REST
REST is no solution for every use case!
So when not to use RESTful APIs?

21. 21
Disadvantages of REST
● Changing REST interfaces and Versioning: If not done well:payloads tend to grow over
time for all clients.
● REST endpoints are usually weakly-typed and lack machine-readable metadata. So use
strong typing when possible!
● No single standard exist for RESTful interfaces. Consequence is that depending on the
service request/response behavior can be different than expected.
● Most REST systems of any complexity end up with large amounts of endpoints. Getting
familiar with all these endpoint and interacting with the correct endpoints can become
hard.
● Doing chained transactions over different REST endpoints providers can become difficult
and can become complex too. (But with good design it is possible!)
● RESTful interfacing can have a large impact on network load. (REST with video, audio, big-
data files …) Sometimes using pure ftp-protocol is not that bad...
● REST is hard to use when fetching complicated object graphs that require multiple round
trips between the client and server to render single views.

22. 22
Tools to work with REST
Use the right tool for the job. Working with RESTful interfaces
requires of always testing interfaces. Some tool examples:
● cURL (The defacto CLI tool for years!) (
https://curl.haxx.se/docs/)
● wget
● HTTPIE (Python CLI, http://httpie.org )
● REST Easy (A firefox plugin)
● Postman (Chrome extensions or standalone)

23. 23
Questions / Discussion
#BuildTogether

24. 24
Summary
 Essence of REST
 How does REST work?
 Designing RESTful APIs
 Advantages and Disadvantages of REST
 Tools to work with REST

25. 25
Appendix: Designing RESTful APIs (2)
REST interfaces are defined through the URL or URI:
 URN: Universal Resource Name
 Name of a resource in-depended of a specific location
 URL: Uniform Resource LOCATION
 Provides access to a specific representation of a resource on the
network.
 Example: https://myapp.jexia.com/mypizza?ordernumber=60
 Example:https://myapp.jexia.com/mypizza/ordernumber/60
 URI: Uniform Resource IDENTIFIER (can be URL or URN)
 Identifies a specific resource on the network
 Example: https://myapp.jexia.com/mypizza
 mailto:<questions@jexia.com>