CS计算机代考程序代写 scheme database Java distributed system case study Excel SE457 Week 4

SE457 Week 4 – REST
Steven Engelhardt
DePaul University
Spring 2021
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 1 / 74

Table of Contents
1 Last Week
2 Quiz 1 Review
3 Homework 1 Review
4 Quiz 2 Review
5 Class Discussion: Microservices
6 REST
Introduction to REST JAX-RS
7 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 2 / 74

Last Week
• Discussed similarity of service-oriented architecture principles to object-oriented software development principles
• Discussed importance of governance in SOA implementations
• Introduction to XML, including namespaces and schemas
• Introduction to SOAP, including WSDL
• Introduction to JAX-WS, the Java standard for implementing SOAP-based web services
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 3 / 74

Research Presentation Topics
• Everyone should have received an email with the status of their research presentation (approved or needs work). If you did not receive an email, contact me ASAP.
• All choices will be approved within a few days.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 4 / 74

Question 1a
(6 point(s)) Please select the definition that matches each of the terms below.
Service
1 A coordinated aggregate of services drawn from a service inventory.
2 A collection of self-contained business functionality that exist as applications with their own design characteristics that support the strategic goals of the organization.
3 An independently standardized and governed collection of complementary services within the boundary of an enterprise or segment of an enterprise.
4 A service offered by an electronic device to another electronic device, communicating with each other via HTTP/HTTPS
5 A service whose functional boundary is related to one or more business processes
6 A service whose functional boundary is non-business-centric
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 6 / 74

Question 1b
(6 point(s)) Please select the definition that matches each of the terms below.
Web service
1 A coordinated aggregate of services drawn from a service inventory.
2 A collection of self-contained business functionality that exist as applications with their own design characteristics that support the strategic goals of the organization.
3 An independently standardized and governed collection of complementary services within the boundary of an enterprise or segment of an enterprise.
4 A service offered by an electronic device to another electronic device, communicating with each other via HTTP/HTTPS
5 A service whose functional boundary is related to one or more business processes
6 A service whose functional boundary is non-business-centric
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 7 / 74

Question 1c
(6 point(s)) Please select the definition that matches each of the terms below.
Task service
1 A coordinated aggregate of services drawn from a service inventory.
2 A collection of self-contained business functionality that exist as applications with their own design characteristics that support the strategic goals of the organization.
3 An independently standardized and governed collection of complementary services within the boundary of an enterprise or segment of an enterprise.
4 A service offered by an electronic device to another electronic device, communicating with each other via HTTP/HTTPS
5 A service whose functional boundary is related to one or more business processes
6 A service whose functional boundary is non-business-centric
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 8 / 74

Question 1d
(6 point(s)) Please select the definition that matches each of the terms below.
Utility service
1 A coordinated aggregate of services drawn from a service inventory.
2 A collection of self-contained business functionality that exist as applications with their own design characteristics that support the strategic goals of the organization.
3 An independently standardized and governed collection of complementary services within the boundary of an enterprise or segment of an enterprise.
4 A service offered by an electronic device to another electronic device, communicating with each other via HTTP/HTTPS
5 A service whose functional boundary is related to one or more business processes
6 A service whose functional boundary is non-business-centric
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 9 / 74

Question 1e
(6 point(s)) Please select the definition that matches each of the terms below.
Service composition
1 A coordinated aggregate of services drawn from a service inventory.
2 A collection of self-contained business functionality that exist as applications with their own design characteristics that support the strategic goals of the organization.
3 An independently standardized and governed collection of complementary services within the boundary of an enterprise or segment of an enterprise.
4 A service offered by an electronic device to another electronic device, communicating with each other via HTTP/HTTPS
5 A service whose functional boundary is related to one or more business processes
6 A service whose functional boundary is non-business-centric
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 10 / 74

Question 1f
(6 point(s)) Please select the definition that matches each of the terms below.
Service inventory
1 A coordinated aggregate of services drawn from a service inventory.
2 A collection of self-contained business functionality that exist as applications with their own design characteristics that support the strategic goals of the organization.
3 An independently standardized and governed collection of complementary services within the boundary of an enterprise or segment of an enterprise.
4 A service offered by an electronic device to another electronic device, communicating with each other via HTTP/HTTPS
5 A service whose functional boundary is related to one or more business processes
6 A service whose functional boundary is non-business-centric
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 11 / 74

Question 2
(1 point(s)) What is the common service classification scheme that we discussed in week 1’s lecture?
1 Entity, Utility, Web Service
2 Task, RESTful, SOAP
3 Entity, Utility, RESTful
4 Entity, Utility, Task
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 12 / 74

Question 3
(1 point(s)) Explain the relationship between SOA and web services.
1 You cannot have SOA without web services; they are inseperable.
2 Web services are the most common way to achieve SOA, but you can have SOA without them.
3 Web services are SOA; they are the same concept.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 13 / 74

Question 4
(1 point(s)) Which of the below items are considered part of the service contract? Mark all that apply.
1 The technical interface, or API, of the service
2 The security policy of the service
3 The availability schedule, response time guarantees, and charge-back costs of the service
4 The programming language in which the service is written
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 14 / 74

Question 5
(1 point(s)) Which of the following are the preferred forms of coupling? Mark all that apply.
1 Consumer-to-Implementation 2 Logic-to-Contract
3 Contract-to-Logic
4 Contract-to-Technology
5 Consumer-to-Contract
6 Contract-to-Implementation 7 Contract-to-Functional
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 15 / 74

Question 1
Q Interoperability requires industry-wide standards. Explain whether or not you think this statement is accurate and why.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 17 / 74

Question 1
Q Interoperability requires industry-wide standards. Explain whether or not you think this statement is accurate and why.
A We could say that yes, interoperability requires industry standards. However, that really depends on the scope of the interoperability required. Almost anything will work within, say, a department. The problem will arise when you want applications from one department to interoperate with applications from another. Then you need to negotiate some kind of shared standard. As the scope of interoperability widens, this negotiation becomes harder and harder. The benefit of using industry standards is that it represents the culmination of these negotiations and provides you with the greatest possibility of interoperability. So the real answer is “it depends”, and it depends on the scope of the interoperability desired and what is already in place. The other benefit of using industry standards is that you don’t have to spend a lot of time dreaming up new interoperability schemes; that work has already been done for you.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 17 / 74

Question 2
Q Two things we worry about in distributed systems are network chattiness and data volume. Network chattiness happens when there are a lot of requests between a client and a service. Data volume is concerned with the amount of data passed in each request. Explain how a strongly standardized data representation could result in network chattiness or, conversely, in wasted network bandwidth because of large data volumes. Hint: consider the impact of a standardized data representation with different degree of granularity.
A Standardized data representations are intended to represent business entities. That’s where entity services come into play.
If the representation is too fine-grained, then it may take many calls with smaller amounts of data to complete a process. Conversely, if the representation is too coarse-grained, then we may pass a lot of additional data that the service doesn’t need, which is wasteful of bandwidth and processing resources.
As with everything, there needs to be a balance.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 18 / 74

Question 3
Q Service-orientation defines a trade-off where services are typically delivered more slowly and applications delivered more quickly than in non-SOC approaches. What arguments are used to justify why this trade-off is acceptable? What assumptions must be made for this claim to be true?
A The basic reason that we develop services more slowly is that they need to be crafted in such a way as to demonstrate the properties that services are supposed to have: reusability, abstraction, loose coupling, autonomy, discoverability, statelessness, standardization, and composability.
The premise is that if we invest the time up front on good service design, we’ll gain benefits later on when we need to build the overall solution because we’ll have less logic to write – we can instead focus on composition with minimal “glue” to hold everything together.
However, this isn’t always going to be true. One of the first assumptions is that an existing inventory of services is present. If we’re just starting out, then there are no services to reuse and so there won’t be any time savings. The savings come into play as the inventory grows. This also assumes that the majority of solutions are built using existing services rather than new ones and that just may not be accurate.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 19 / 74

Question 4
Q Service-orientation claims that often the overall amount of application logic in an organization is reduced. What arguments are used to justify this claim? What assumptions must be made for this claim to be true?
A By moving to services, we try to emphasize reuse. By emphasizing reuse we’re able to cut down on the amount of redundant solution logic within our application domain. That, in turn, reduces the overall amount of solution logic present in our organization.
It’s more or less the same line of reasoning we use to justify using 3rd normal form in a database to prevent the issues of duplication and consistency that arise when we’re dealing with business data.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 20 / 74

Question 5
Q Considering the challenges that come with service composition from the perspective of understanding and troubleshooting an application, why might service-oriented systems be just as complex as other custom-developed systems?
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 21 / 74

Question 5
Q Considering the challenges that come with service composition from the perspective of understanding and troubleshooting an application, why might service-oriented systems be just as complex as other custom-developed systems?
A Done well, each service will have only one responsibility. This is great in terms of encapsulating the logic in one place. However, for a complex business process to be performed, multiple services will typically need to be composed (e.g. a task service using multiple entity services). This can make it harder to trace a call across multiple services to identify and troubleshoot problems. This also makes the entire business process harder to understand and more complex to evolve, even if it isn’t more complex to actually use.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 21 / 74

Question 1a
(8 point(s)) Please match the design principles with their definitions below. Services in the same inventory follow the same contract design standards.
1 Abstraction
2 Autonomy
3 Composability 4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 23 / 74

Question 1b
(8 point(s)) Please match the design principles with their definitions below. Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.
1 Abstraction
2 Autonomy
3 Composability 4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 24 / 74

Question 1c
(8 point(s)) Please match the design principles with their definitions below. A service contract only contains essential information, and information about a service is limited to what is published in its contract.
1 Abstraction
2 Autonomy
3 Composability 4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 25 / 74

Question 1d
(8 point(s)) Please match the design principles with their definitions below. A service contains agnostic logic and can be positioned as a reusable enterprise resource.
1 Abstraction
2 Autonomy
3 Composability 4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 26 / 74

Question 1e
(8 point(s)) Please match the design principles with their definitions below. Services exercise a high level of control over their underlying execution environment.
1 Abstraction
2 Autonomy
3 Composability 4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 27 / 74

Question 1f
(8 point(s)) Please match the design principles with their definitions below. Services minimize resource consumption by deferring the management of state information when necessary.
1 Abstraction
2 Autonomy
3 Composability 4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 28 / 74

Question 1g
(8 point(s)) Please match the design principles with their definitions below. Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
1 Abstraction
2 Autonomy
3 Composability 4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 29 / 74

Question 1g
(8 point(s)) Please match the design principles with their definitions below. Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
1 Abstraction
2 Autonomy
3 Composability
4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 29 / 74

Question 1h
(8 point(s)) Please match the design principles with their definitions below. Services are effective composition participants, regardless of the size and complexity of the composition.
1 Abstraction
2 Autonomy
3 Composability 4 Contracts
5 Coupling
6 Discoverability 7 Reuse
8 Statelessness
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 30 / 74

Question 2
(1 point(s)) What impact will increasing a service’s dependencies have on it’s autonomy?
1 Its autonomy will increase.
2 Its autonomy will decrease.
3 Its autonomy will increase as long as the dependent services are themselves autonomous. Otherwise it will decrease.
4 There will be no impact.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 31 / 74

Question 3
(1 point(s)) Statelessness and state deferral are most concerned with improving which of the following architectural concerns?
1 Performance 2 Security
3 Scalability
4 None of these
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 32 / 74

Question 4a
(4 point(s)) Please select the SOC pattern that best matches each of the definitions below.
Either an existing service will be used or a new service will be developed.
1 Logic Centralization
2 Contract Centralization
3 Service Normalization
4 Domain Inventory
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 33 / 74

Question 4b
(4 point(s)) Please select the SOC pattern that best matches each of the definitions below.
Minimizes the amount of functional redundancy within a service inventory.
1 Logic Centralization
2 Contract Centralization
3 Service Normalization
4 Domain Inventory
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 34 / 74

Question 4c
(4 point(s)) Please select the SOC pattern that best matches each of the definitions below.
The choice of how to access a service is limited to only the service’s contract.
1 Logic Centralization
2 Contract Centralization
3 Service Normalization
4 Domain Inventory
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 35 / 74

Question 4d
(4 point(s)) Please select the SOC pattern that best matches each of the definitions below.
Constrains reuse efforts to manageable scales such as departments or functional areas.
1 Logic Centralization
2 Contract Centralization
3 Service Normalization
4 Domain Inventory
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 36 / 74

Question 5a
(5 point(s)) Match the following object-oriented design principles to SOA design principles.
Don’t repeat yourself (DRY)
1 Service abstraction
2 Service normalization
3 Service reusability
4 Service-level granularity
5 Standardized service contract
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 37 / 74

Question 5b
(5 point(s)) Match the following object-oriented design principles to SOA design principles.
Encapsulation
1 Service abstraction
2 Service normalization
3 Service reusability
4 Service-level granularity
5 Standardized service contract
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 38 / 74

Question 5c
(5 point(s)) Match the following object-oriented design principles to SOA design principles.
Generalization / specialization
1 Service abstraction
2 Service normalization
3 Service reusability
4 Service-level granularity
5 Standardized service contract
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 39 / 74

Question 5d
(5 point(s)) Match the following object-oriented design principles to SOA design principles.
Open-closed principle
1 Service abstraction
2 Service normalization
3 Service reusability
4 Service-level granularity
5 Standardized service contract
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 40 / 74

Question 5e
(5 point(s)) Match the following object-oriented design principles to SOA design principles.
Polymorphism
1 Service abstraction
2 Service normalization
3 Service reusability
4 Service-level granularity
5 Standardized service contract
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 41 / 74

The State of the Art in Microservices by Adrian Cockroft
1 How would you summarize the key points of Cockroft’s talk?
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 43 / 74

The State of the Art in Microservices by Adrian Cockroft
1 How would you summarize the key points of Cockroft’s talk?
2 Cockroft described Docker as a “case study of how to build a totally viral developer driven product launch”. Does this agree with your experience? Why do you think Docker was so viral?
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 43 / 74

The State of the Art in Microservices by Adrian Cockroft
1 How would you summarize the key points of Cockroft’s talk?
2 Cockroft described Docker as a “case study of how to build a totally viral developer driven product launch”. Does this agree with your experience? Why do you think Docker was so viral?
3 How do your personal experiences align with Cockroft’s point of view? Please share anecdotes if you can.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 43 / 74

A brief history of REST
• REST stands for REpresentational State Transfer.
• Roy Fielding developed REST in his PhD dissertation.
• Dr. Fielding is one of the principal authors of the HTTP specification and is a cofounder of the Apache Foundation.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 46 / 74

RESTful web services are different from SOAP-based web services
• SOAP is a messaging protocol that uses HTTP as a transfer mechanism.
• REST depends on the semantics that are inherent in the HTTP protocol itself.
• In particular it takes advantage of URIs, HTTP verbs, and the MIME type system.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 47 / 74

REST is getting more and more popular
Figure: https://trends.google.com/trends/ex- plore?date=all&q=GraphQL,REST%20API,OData,WSDL,gRPC
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 48 / 74

SOAP services typically focus on operations

123

Tony Stark

Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 49 / 74

REST deals with resources and representations
• A resource is anything that can be accessed using HTTP.
• Each resource has a name in the form of a URI.
• Each resource has a type, or representation, in the form of a MIME type.
• Resources have state. What that state is and how much of it is available for each request depends on the service’s goals.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 50 / 74

Resources are anything identifiable
• A document
• An image
• The time where you are
• The time somewhere else
• Your bank balance
• Information about you
• Information about your friends • The result of invoking a service
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 51 / 74

Identifiers are important
Properties
• Global
• Disambiguable • Resolvable
Examples
• Employee ids
• SSNs
• E-mail address • Phone number • Twitter account • Web address
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 52 / 74

Rest treats HTTP as an API
• HTTP is concerned with accessing named resources using their URLs.
• HTTP already provides “methods”.
• The HTTP response has a MIME type.
• The state of the resource is returned in the response as the actual payload.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 53 / 74

Example REST GET Request
Request
GET /users/123 HTTP/1.1 Host: example.com
Response
HTTP/1.1 200 OK
Content-Type: application/json
{
“id”: 123,
“username”: “Tony Stark”,
… }
Steven Engelhardt (DePaul University)
SE457 Week 4 – REST
Spring 2021
54 / 74

REST requires a resource and a verb
• The resource is just a URI.
• The verb is one of the standard
HTTP request methods.
HTTP Verb
GET POST PUT DELETE PATCH OPTIONS
HEAD
CRUD Operation
Read
Create
Update
Delete
Partial Update
List allowed operations on a resource
Return only the re- sponse headers and no response body
Steven Engelhardt (DePaul University) SE457 Week 4 – REST
Spring 2021 55 / 74

Resource and Verb form a Request
Uniform Resource Locator (URL)
Collection,
such as https: //api.example. com/resources/
GET
List the URIs and perhaps other de- tails of the collec- tion’s members.
Retrieve a repre- sentation of the addressed mem- ber of the col- lection, expressed in an appropri- ate Internet me- dia type.
PUT
Replace the en- tire collection with another collection.
Replace the ad- dressed member of the collection, or if it does not exist, create it.
PATCH
Not generally used
Update the ad- dressed member of the collection.
POST
Create a new en- try in the collec- tion. The new entry’s URI is as- signed automati- cally and is usu- ally returned by the operation. Not generally used. Treat the addressed mem- ber as a collection in its own right and create a new entry within it.
DELETE
Delete the entire collection.
Delete the ad- dressed member of the collection.
Element,
as //api.example. com/resources/ item17
such
https:
Table: Source: https://en.wikipedia.org/wiki/Representational_state_transfer
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 56 / 74

Example REQUEST Request: Get All Resources in a Collection
Request
GET /users HTTP/1.1 Host: example.com
Response
HTTP/1.1 200 OK
Date: Sat, 02 Apr 2016 12:22:40 GMT
[
{
}, {
},
… ]
“id”: 123,
“username”: “Tony Stark”, …
“id”: 234,
“username”: “Bruce Banner”, …
Steven Engelhardt (DePaul University)
SE457 Week 4 – REST
Spring 2021
57 / 74

Example REST Request: Create a Resource
Request
POST /users HTTP/1.1
Host: example.com Content-Type: application/json
{
“username”: “Tony Stark”,
… }
Response
HTTP/1.1 201 Created
Date: Sat, 02 Apr 2016 12:22:40 GMT Location: http://example.com/users/123
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 58 / 74

Example REST Request: Update a Resource
Request
PUT /users/123 HTTP/1.1
Host: example.com Content-Type: application/json
{
“id”: 123,
“username”: “Steven Engelhardt”,
… }
Response
HTTP/1.1 200 OK
Date: Sat, 02 Apr 2016 12:22:40 GMT
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 59 / 74

Example REST Request: Delete a Resource
Request
DELETE /users/123 HTTP/1.1 Host: example.com Content-Type: application/json
Response
HTTP/1.1 200 OK
Date: Sat, 02 Apr 2016 12:22:40 GMT
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 60 / 74

HTTP response codes define the result of a request
Status Code
Message
OK
See Other
Bad Request Unauthorized
Forbidden Not Found
Method Not Allowed Internal Server Error
Meaning
Request was satisfied correctly.
The request was redirected to a new resource.
The request was malformed.
There was an error authentication the requestor.
The request was refused.
The requested resource could not be found.
The requested HTTP method isn’t supported by the resource.
An error occurred during request pro- cessing.
200 303
400 401
403 404
405 500
Steven Engelhardt
(DePaul University) SE457 Week 4 – REST Spring 2021 61 / 74

Representation can vary by need
• HTML
• XML
• JSON
• Excel spreadsheet • Rendered image
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 62 / 74

Example REST Request: Get a Different Representation
Request
GET /users/123 HTTP/1.1 Host: example.com Accept: application/xml
Response
HTTP/1.1 200 OK
Content-Type: application/xml

123
Tony Stark …

Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 63 / 74

The body of RESTful messages can be anything
• If you can transfer the data in an HTTP request payload, then you can pass that data to and from a RESTful service.
• Common payloads include: • XML
• JSON
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 64 / 74

Example REST Request: Send a Different Representation
Request
PUT /users/123 HTTP/1.1
Host: example.com Content-Type: application/xml

123
Bruce Banner …

Response
HTTP/1.1 200 OK
Date: Sat, 02 Apr 2016 12:22:40 GMT
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 65 / 74

A Note on JAX-WS
• JAX-WS can theoretically be used to write REST web services with the use of the @WebServiceProvider, @ServiceMode(Value=MESSAGE), and @BindingType(value=HTTP_BINDING) attributes.
• However, this is not recommended. Consider, for all practical purposes, JAX-WS to be SOAP-only.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 67 / 74

JEE servlets are natural implementations for REST services
• Servlets are already designed in a way that they can treat HTTP as an API.
• Since they execute in a web container, we also have the ability to layer on other capabilities such as security, logging, management, etc.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 68 / 74

A brief servlet review
• Servlets typically provide the business logic for a web application and thus make sense as an entry point for the web service.
• Web applications and their servlets are typically packaged as a WAR file and deployed to a JEE web container.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 69 / 74

A basic servlet implementation
• We could hypothetically build a servlet that implements a REST API.
public class RestApiServlet extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException,
IOException
{
} }
// TODO: Parse request
// Send response
response.setContentType(“application/json”); PrintWriter out = response.getWriter(); out.println(“…”);
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 70 / 74

JAX-RS is one alternative to servlets
• JAX-RS (Java API for RESTful Web Services) is an alternative to servlets.
• Unlike JAX-WS, it is not yet bundled with the JDK, but it is part of JEE6.
• JAX-RS is used to place a servlet in front of annotated services.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 71 / 74

Example JAX-RS Class
@Path(“/hello”)
public class Hello {
// This method is called if TEXT_PLAIN is request
@GET
@Produces(MediaType.TEXT_PLAIN)
public String sayPlainTextHello() {
return “Hello Jersey”;
}
// This method is called if XML is request
@GET
@Produces(MediaType.TEXT_XML)
public String sayXMLHello() {
return “” +
“Hello Jersey” + ““;
} }
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 72 / 74

Next Steps
• Homework 2 is available on D2L. It is due Tuesday, April 27 at 5:30PM.
Steven Engelhardt (DePaul University) SE457 Week 4 – REST Spring 2021 74 / 74

Related Posts