3. What is a web
service?
A Web service is a software system designed to support
interoperable machine-to-machine interaction over a
network.
— W3C, Web Services Glossary
We can identify two major classes of Web services:
REST-compliant Web services, in which the primary
purpose of the service is to manipulate XML
representations of Web resources using a uniform set of
”stateless” operations; and arbitrary Web services, in which
the service may expose an arbitrary set of operations.
— W3C, Web Services Architecture (2004)
) 3 / 36
5. REST vs SOAP
Interest
Figure : Interest over time for REST API versus SOAP API based on
Google Insights for Search. Source:
https://www.google.com/trends
) 5 / 36
6. Basic
terms
Uniform Resource Identifier (URI) is a string of characters used
to identify a resource. (e.g.,
http://www.fel.cvut.cz/cz/education/)
The Hypertext Transfer Protocol (HTTP) is an application
protocol for distributed, collaborative, hypermedia
information systems. It is the foundation of data
communication for the World Wide Web.
initiated by Tim Berners-Lee at CERN in 1989
Representational State Transfer (REST) is an architectural
style
for distributed hypermedia systems.
defined in 2000 by Roy Fielding in his doctoral dissertation
) 6 / 36
8. HTTP
HTTP protocol
basics
HTTP is a client-server application-level
protocol Typically runs over a TCP/IP
connection Extensible – e.g., video, image
support
Stateless
Cacheabl
e
Requires ) 8 / 36
12. HTTP
HTTP Methods
GET
Used to retrieve resource at request
URI Safe and idempotent
Cacheable
Can have side effects, but not
expected
Can be conditional or partial (If-
Modified-Since, Range)
POST
Requests server to create new resource from the specified
body Can be used also to update resources
Should respond with 201 status and location of newly
created resource on success
Neither safe nor
) 12 / 36
13. HTTP
HTTP Methods
PUT
Requests server to store the specified entity under the
request URI Server may possibly create a resource if it does
not exist
Usually used to update
resources Idempotent, unsafe
DELETE
Used to ask server to delete resource at the request
URI Idempotent, unsafe
Deletion does not have to be immediate
) 13 / 36
14. HTTP
HTTP Response Status
Codes
1xx – rarely used
2xx – success
200 OK – requests succeeded, usually contains data
201 Created – returns a Location header for new resource
202 Accepted – server received request and started
processing 204 No Content – request succeeded, nothing
to return
3xx – redirection
304 Not Modified – resource not modified, cached version
can be used
) 14 / 36
15. HTTP
HTTP Response Status
Codes
4xx – client error
400 Bad Request – malformed syntax
401 Unauthorized – authentication required
403 Forbidden – server has understood, but refuses request
404 Not Found – resource not found
405 Method Not Allowed – specified method is not
supported 409 Conflict – resource conflicts with client data
415 Unsupported Media Type – server does not support
media type
5xx – server error
500 Internal Server Error – server encountered error and failed
to process request
) 15 / 36
17. RESTful web
services
Understanding REST
REST is an architectural style, not standard
It was designed for distributed systems to address architectural
properties such as performance, scalability, simplicity,
modifiability, visibility, portability, and reliability
REST architectural style is defined by 6
principles/architectural constraints (e.g., client-server,
stateless)
System/API that conforms to the constraints of REST can
be called
RESTful
) 17 / 36
19. RESTful web
services
Building RESTful API
Can be build on top of existing web
technologies Reusing semantics of HTTP 1.1
methods
Safe and idempotent methods
Typically called HTTP verbs in context of
services Resource oriented, correspond to
CRUD operations Satisfies uniform interface
constraint
HTTP Headers to describe requests &
responses Content negotiation
) 19 / 36
24. RESTful web
services
Recommended Interaction of HTTP Methods w.r.t.
URIs
HTTP Verb CRUD Collection (e.g. /categories) Specific Item (e.g. /categories/{id})
POST Create 201 Created1 405 Method Not Allowed /409 Conflict3
GET Read 200 OK, list of categories 200 OK, single category/404 Not Found4
PUT Update/Replace 405 Method Not Allowed2 200 OK/204 No Content/404 Not Found4
PATCH Update/Modify 405 Method Not Allowed2 200 OK/204 No Content/404 Not Found4
DELETE Delete 405 Method Not Allowed2 200 OK/204 No Content/404 Not Found4
Table : Recommended return values of HTTP methods in combination
with the resource URIs.
1 – returns Location header with link to /categories/{id} containing
new ID
2 – unless you want to update/replace/modify/delete whole collection
3 – if resource already exists
4 – if ID is not found or invalid
) 24 / 36
25. RESTful web
services
Naming conventions
resources should have name as nouns, not as verbs or
actions plural if possible to apply
URI should follow a predictable (i.e., consistent usage) and
hierarchical structure (based on structure-relationships of
data)
Correct usages
POST /customers/12345/orders/121/items
GET /customers/12345/orders/121/items/3
GET|PUT|DELETE /customers/12345/configuration
Anti-patterns
GET /services?op=update customer&id=12345&format=json
PUT /customers/12345/update
) 25 / 36
26. RESTful web
services
The Richardson Maturity
Model
provides a way to evaluate compliance of API to REST
constraints
Figure : A model (developed by Leonard Richardson) that breaks down
the principal elements of a REST approach into three steps about
resources, http verbs, and hypermedia controls. Source: http:
//martinfowler.com/articles/richardsonMaturityModel.ht
ml
) 26 / 36
27. 27 /
•Decoupling: HATEOAS decouples the client and
server, allowing server functionality to evolve
independently.
•Discoverability: HATEOAS makes APIs more
discoverable and easier to use.
•Flexibility: HATEOAS improves the flexibility and
evolvability of RESTful APIs.
•Usability: HATEOAS can improve the usability and
adaptability of web services and APIs.
To successfully implement HATEOAS, it's
important to design clear resource relationships,
include relevant hypermedia links, and use
standardized media types.
28. HATEOAS
28 /
Hypermedia as the Engine of Application State (HATEOAS) is a
REST API architectural constraint that allows clients to interact
with a network application without needing to know much about
the application or server.
HATEOAS works by including hypermedia links in API responses,
which provide information about the current state of the
application, possible actions, and available transitions. This
allows clients to navigate and interact with resources
dynamically, without needing to know the API structure
beforehand.
HATEOAS has several benefits, including:
29. RESTful web services HATEOAS
HATEOAS
Hypermedia as the Engine of Application State
Final level of the Richardson Maturity Model
Client needs zero or little prior knowledge of an
API Client just needs to understand
hypermedia
Server provides links to further
endpoints Often difficult to
implement
Not many usable libraries
) 29 / 36
30. RESTful web services HATEOAS
HATEOAS Example
*EAR e-shop does not support
HATEOAS.
{
"id": 2,
"name": "CPU",
"links": [{
"rel": "self",
"href": "http://localhost:8080/eshop/rest/categories/2"
}, {
"rel": "edit",
"href": "http://localhost:8080/eshop/rest/categories/2"
}, {
"rel": "products",
"href": "http://localhost:8080/eshop/rest/categories/2/products"
}]
}
We are using the Atom link
format.
) 30 / 36
32. Linked Data
Linked Data
Method of publishing structured data allowing to interlink
them with other data
Builds upon the original ideas of the Web
Interconnected resources, but this time, machine-readable
Knowledge-based systems, context-aware applications, precise
domain description, knowledge inference
Still possible to build REST APIs, but resources have global
identifiers now
Attributes and relationships also globally identifiable and
may have well-defined meaning
) 32 / 36
33. Linked Data
Linked Data
Example
{
"@context": {
"name": "http://www.w3.org/2000/01/rdf-schema#label",
"description": "http://purl.org/dc/terms/description",
"products":
"http://onto.fel.cvut.cz/ontologies/eshop/has-product"
},
"@id": "http://onto.fel.cvut.cz/eshop/categories/cpu",
"products": {
"@id": "https://ark.intel.com/products/97455/Intel-
Core-i3-7100-
Processor-3M-Cache-3-90-GHz",
"name": "Intel Core i3-7100"
},
"description": "Category of Central Processing Units for
computers.", "name": "CPU"
}
) 33 / 36
34. Conclusion
s
REST
Pros
Easy to
build Easy
to use
Standard technologies – HTTP, JSON,
XML Platform-independent
Stateless, cacheable
Cons
No standard for REST itself – APIs build
in various ways
No standard for documentation and publishing REST API
description No “registry” of REST services
) 34 / 36