Design Web Application Component and APIs

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 25

Model and Design of Web

Application Components

Professor Athula Ginige


Professor of Information Technology
Dr. Chris D’Souza (Lecturer & Tutor)
Western Sydney University
Australia
Items for Week 4 Discussion
Motivation
Impact of Changing Business Requirements
Separation of concerns – M V C
MVC in Web 1.0
MVC in Web 2.0
Single Page Architecture
HTTP methods and APIs

© Athula Ginige, WSU


Motivation
Maintenance cost is higher than development costs
Why?
 Porter’s model of competitive forces demands businesses need to
consistently evolve to be competitive
1. Competition in the industry
2. Potential of new entrants into the industry
3. Power of suppliers
4. Power of customers
5. Threat of substitute products
SELT reasons
Social
Environment
Legal
Technological
© Athula Ginige,
Impact of change
Business processes can change
Make it easier to change the business entities
Make the Models loosely coupled from one another
Stakeholders can change
Make it easier to change stakeholders’ perspective
Make the Views loosely coupled from each other

Management Control can change


Make it easier to change management control

Make the Controller loosely coupled from each other


© Athula Ginige,
Separation of Concerns
– MVC Architecture
• This was proposed by Trygve Reenskaug to
bridge the gap between the human user's mental
model and the digital model that exists in the
computer.
Logical Design – MVC
Architecture

MODE CONTROLLE VIEW


L R

USER
Logical Design – MVC Architecture
Model
• The Model is responsible for manipulating the data
• The Model represents the application core (for
instance a list of database records).
• In 4-tier architecture, Model is loosely coupled from
the database engine. That is, does not contain SQL
statements
• The Model represents the data structures. It will
contain functions that help you retrieve, insert and
update information in your database.
Logical Design – MVC
Architecture
View
• The View displays the data ( the database
records).
• In most Web Applications - the View is the sub-
component that produces the HTML page.
• But a View can produce a native application
front end as well
• View should be responsive to the front end
device sizes
Logical Design – MVC
Architecture
Controller
• The Controller is the part of the application that
handles user interaction.
• It manages the invocation of Model and View
requests
• Typically, a controller decides which View
component needs to be executed for the user to
interact with
• When the user sends a request, it decides which
Model(s) need to be used to service the request.
• When the Models respond, it again decides which
MVC in Web 1.0

Response times?
Richness of user interactive-ness?
MVC in Web 2.0

Response times?
Richness of user interactive-ness?
Single Page Application

Ref: Pros and Cons of Building Single Page Applications in 2019 - Gearheart
Single Page Architecture

Ref: Pros and Cons of Building Single Page Applications in 2019 - Gearheart
SPA Example

Ref: Pros and Cons of Building Single Page Applications in 2019 - Gearheart
Why Businesses Love SPA

Ref: Pros and Cons of Building Single Page Applications in 2019 - Gearheart
Pros of SPA
•Reduced throughput – Small sized JSON data
makes it amenable
•Fast response to low-speed
– Except for connections
initial
•Cachingload time
capabilities –
•Offline
Increasedoperations
performance – reduced
number
•Continuousof server roundbeginning
UX – Clear trips
UX, middle UX, end UX
•Adaptable layout. For mobile and other types
of devices

Ref: Pros and Cons of Building Single Page Applications in 2019 - Gearheart
Cons of SPA

•Poor SEO optimization. – lack of unique URL for


•different
Learning services
curve is steeper when using
client-side
•Compared frameworks
to multipage application, SPA is more
prone to Cross-Site Scripting (XSS)

Ref: Pros and Cons of Building Single Page Applications in 2019 - Gearheart
Mix of MPA and SPA

•Each category in a multiple category service


can be designed as a Single Page

Ref: Pros and Cons of Building Single Page Applications in 2019 - Gearheart
Improving server’s performance
During HTTP method calls
•Stateless request : Keep Session state entirely on the client so that server does
not get overloaded when
•when concurrent clients are connected
Request headers: Pass additional instructions along with the request to tell the
server how to interpret the request. These might define the type of response required or the
authorization details.
•Cacheable: the data within a response to a request can be implicitly or explicitly labelled
as cacheable or non-cacheable so that similar repeat request can be avoided
•Repeated requests due to network failures :
Unpredictable response due to failures can be avoided by designing service capabilities with
idempotent logic that enables them to safely accept repeated message exchanges
Idempotency guarantees that repeated invocations of a service capability are safe
and will have no negative effect.
Idempotent capabilities are generally limited to read-only data retrieval and queries.
For capabilities that do request changes to service state, their logic is generally
based on “set”, “put” or “delete” actions that have a post-condition that does not
depend on the original state of the service.

These are useful in load balancing proxies. E.g.,


HAProxy
Benefits of Idempotency: Idempotency Concept
Roadmap Prototype (fenniak.net) – An interactive
HTTP Methods Types
Safe

Idempotent Idempotent methods guarantee


repeating a request has the same
effect as making the request once.
Safe methods:
E.g.,
always idempotent a=4; is idempotent
a=a+1 is not idempotent
Non-idempotent since both change a’s value, they are non-
methods:
always non-safe
Idempotency is important in building a fault-
safe.
tolerant API.
Ref: What are idempotent and/or safe methods? - The RESTful cookbook (restcookbook.com)
Common HTTP Methods
GET – To retrieve resource. It is safe and idempotent.

DELETE – To delete a resource. It is non-safe and idempotent

Ref: What are idempotent and/or safe methods? - The RESTful cookbook (restcookbook.com)
HTTP Method – Response Code

HTTP Entire Collection (e.g. Specific Item (e.g.


Verb CRUD /customers) /customers/{id})
POST Create 201 (Created), 'Location' header 404 (Not Found), 409
with link to /customers/{id} (Conflict) if resource
containing new ID. already exists..
GET Read 200 (OK), list of customers. Use 200 (OK), single
pagination, sorting and filtering customer. 404 (Not
to navigate big lists. Found), if ID not found or
invalid.
PUT Update/ 405 (Method Not Allowed), 200 (OK) or 204 (No
Replace unless you want to Content). 404 (Not
update/replace every resource Found), if ID not found or
in the entire collection. invalid.
PATC Update/ 405 (Method Not Allowed), 200 (OK) or 204 (No
H Modify unless you want to modify the Content). 404 (Not
collection itself. Found), if ID not found or
invalid.
DELET Delete 405 (Method Not Allowed), 200 (OK). 404 (Not
E HTTP Methods for RESTful Services (restapitutorial.com)
unless you want to delete the Found), if ID not found or
Why API design is important
• APIs can be among a company's greatest
assets
_ Customers invest heavily: buying, writing,
learning
_ Cost to stop using an API can be prohibitive
_ Successful public APIs capture customers
• Can also be among company's greatest
liabilities
_ Bad APIs result in unending stream of support
calls
• Public APIs are forever
- one chance to get it right
• If you program, you are an API designer
_ Good
Ref: code is modular–each
32713.pdf module has an API
(googleusercontent.com)
Characteristics of a good API

• Easy to learn
• Easy to use, even without documentation
• Hard to misuse
• Easy to read and maintain code that uses it
• Sufficiently powerful to satisfy requirements
• Easy to extend
• Appropriate to audience

Ref: 32713.pdf (googleusercontent.com)


Process of API Design

Gather Requirements: use cases, user stories


Initially a flexible agile API is better than a
completed API
Code to your API early and often – unit testing
Writing to Service Provide Interface is important
Sufficiently powerful to satisfy requirements
Easy to extend
Appropriate to audience

Ref: 32713.pdf (googleusercontent.com)

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy