Skip to content
CampusPrep
CS-701 · Software Architectures/Quick Revision Short Notes

Software Architectures (CS-701) - Unit 2 Short Notes

How unit 2 is examined

This unit covers the architecture models and styles; pipes and filters, microservices and REST carry the marks, and a comparison of styles is asked often.

Structural models

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A structural model shows the static organisation of a system as components, connectors and their configuration, a framework model gives reusable domain-specific architectures, and a dynamic model shows run-time behaviour.</mark>

Key points.

  1. A structural model describes the components (modules, classes, subsystems) and how they are connected, so it answers "what is the system made of".
  2. A framework model captures a reusable skeleton for a domain, such as a web application framework, which the developer fills in.
  3. A dynamic model shows how the structure behaves over time through interactions, states and messages.
  4. The three are complementary views of one architecture and are drawn with different notations.
Basis Structural model Framework model Dynamic model
Purpose Show static organisation Give a reusable domain architecture Show run-time behaviour
Representation Component and connector diagram, class diagram Reference architecture, framework skeleton Sequence, state and activity diagrams
Viewpoint Design-time, static Reuse, domain Run-time, behavioural
Example Layered component diagram Spring or Struts skeleton Login sequence diagram

Answer frame. Open with the three definitions; draw the table above with purpose, representation, viewpoint and example rows; close by saying the three views together describe one architecture.

Asked: [7 marks] (Dec 2024) Compare structural model, framework model and dynamic model.

Framework models

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>A framework model is a reusable, partly complete architecture for a family of applications, whose fixed structure and extension points are filled in by the developer.</mark>

Key points.

  1. It fixes the common structure and control flow of a domain, so the developer writes only the application-specific parts.
  2. It gives reuse and a consistent design, for example MVC web frameworks.
  3. Its weakness is inversion of control, because the framework calls your code and limits your freedom.

Dynamic models

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>A dynamic model describes the behaviour of the architecture at run time: how components interact, exchange messages and change state.</mark>

Key points.

  1. It is drawn with sequence, collaboration, state and activity diagrams.
  2. It shows the order of calls and events, which a static structure cannot show.
  3. It is used to check performance, deadlock and response to events.

Process models

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>A process model (process or concurrency view) shows the run-time processes, threads and their communication and synchronisation.</mark>

Key points.

  1. It maps components onto processes and threads and shows how they communicate.
  2. It addresses concurrency, performance, availability and scalability.
  3. It is drawn as process diagrams showing inter-process links.

Dataflow architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Dataflow architecture is a style in which the system is a series of transformations applied to data as it moves from input to output, with no shared state; batch sequential and pipes and filters are its variants.</mark>

Key points.

  1. In batch sequential each stage finishes on the whole data set before the next starts, whereas in pipes and filters the stages work incrementally.
  2. Components are independent, so they are reusable and easy to reorder.
  3. It suits compilers and data processing but not interactive systems.

Comparison of styles (for the comparative study).

Style Components / connectors Control and data Typical example
Pipe and filter Filters / pipes Data flows one way, no shared state Compiler, UNIX pipeline
Layered Layers / procedure calls Each layer uses the one below OSI model, operating system
Client-server Client, server / requests Client initiates, server responds Web, database
MVC Model, view, controller / events Controller mediates user input Web application UI
SOA Services / messages, ESB Loosely coupled service calls Banking services
Repository Central store, clients / shared data Data drives control IDE, database system
Event-based Publishers, subscribers / events Events trigger handlers GUI, notification

Choose the style by the dominant quality attribute: reuse (pipe and filter), modifiability (layered), scalability (client-server, SOA), integrability (repository), responsiveness (event-based).

Asked: [7 marks] (Dec 2020, Nov 2022, Jun 2025) Perform a comparative study of the different architectural styles. Describe different types of software architecture models. List and define any two software architecture styles with their characteristics.

Pipes and filters architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>Pipes and filters is a dataflow style in which independent components called filters each transform an input data stream into an output stream, and connectors called pipes carry the data from one filter to the next.</mark>

Diagram.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u2-01" viewBox="0 0 596 80" width="596" height="80" role="img" aria-label="Pipe and filter: filters F1 to F3 joined by pipes, data flows left to right"><style>#dsfig-u2-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u2-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u2-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u2-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u2-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u2-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u2-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u2-01 .t{fill:#16181D;font-weight:500}#dsfig-u2-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u2-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u2-01 .dot{fill:#16181D}#dsfig-u2-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u2-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u2-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u2-01 .ah{fill:#454C5A}#dsfig-u2-01 .ah.hi{fill:#2340B8}#dsfig-u2-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u2-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u2-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u2-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u2-01 .e{stroke:#B1B7C3}html.dark #dsfig-u2-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u2-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u2-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u2-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u2-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u2-01 .t{fill:#E6E8ED}html.dark #dsfig-u2-01 .t.inv{fill:#0F1115}html.dark #dsfig-u2-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u2-01 .dot{fill:#E6E8ED}html.dark #dsfig-u2-01 .ann{fill:#8FA3FF}html.dark #dsfig-u2-01 .lbl{fill:#858D9C}html.dark #dsfig-u2-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u2-01 .ah{fill:#B1B7C3}html.dark #dsfig-u2-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u2-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u2-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u2-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah6" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh6" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,40 L148,40" marker-end="url(#ah6)"/><path class="e" d="M188,40 L277,40" marker-end="url(#ah6)"/><path class="e" d="M317,40 L406,40" marker-end="url(#ah6)"/><path class="e" d="M446,40 L535,40" marker-end="url(#ah6)"/><g class="wl"><rect x="84.1" y="31" width="40.8" height="18" rx="9"/><text class="t" x="104.5" y="40" dy=".35em" text-anchor="middle">data</text></g><g class="wl"><rect x="213.1" y="31" width="40.8" height="18" rx="9"/><text class="t" x="233.5" y="40" dy=".35em" text-anchor="middle">pipe</text></g><g class="wl"><rect x="342.1" y="31" width="40.8" height="18" rx="9"/><text class="t" x="362.5" y="40" dy=".35em" text-anchor="middle">pipe</text></g><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">In</text><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">F1</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">F2</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">F3</text><circle class="n" cx="556" cy="40" r="18"/><text class="t" x="556" y="40" dy=".35em" text-anchor="middle">Out</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Pipe and filter: filters F1 to F3 joined by pipes, data flows left to right</figcaption></figure>

Key points.

  1. A filter reads data from its input pipe, transforms or enriches it, and writes the result to its output pipe, and it knows nothing about the other filters.
  2. A pipe is a connector that moves the stream between filters and may buffer it, so it gives one-way data flow.
  3. Processing is incremental, because a filter can start output before it has consumed all its input, so filters run concurrently.
  4. Advantages: filters are reusable, can be rearranged freely, and the design is easy to understand and extend.
  5. Advantages: it supports concurrency and parallel execution, and the overall behaviour is the composition of the filters.
  6. Disadvantages: it is unsuitable for interactive applications, has no shared state, and data conversion between filters costs overhead.
  7. Disadvantages: error handling is hard and a slow filter becomes the bottleneck.
  8. Examples: the UNIX pipeline ls | grep | sort, compilers (lexer, parser, code generator) and signal or image processing.

Answer frame. Open with the definition of filter and pipe; draw the diagram; develop points 1-3, then advantages 4-5, disadvantages 6-7; close with UNIX pipes and compilers as examples.

Asked: [7 marks] (Dec 2020, Nov 2022, Nov 2023) Explain pipes and filters in detail. Write a short note on pipes and filter architecture.

Call-and-return architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>Call-and-return architecture is a style in which a main program calls subprograms and control returns to the caller after each finishes, giving a hierarchy of components.</mark>

Key points.

  1. Its variants are the main program and subroutine style, remote procedure call (RPC) across machines, and object-oriented style with method calls.
  2. Importance: it decomposes the system into modules, so it gives modularity and a clear control hierarchy.
  3. Procedures and objects can be reused, and a change inside one module does not affect its callers, which helps maintainability.
  4. It is easy to understand and is used in most conventional programs and in distributed systems using RPC or RMI.

Asked: [7 marks] (Dec 2024) What is the importance of call and return architecture?

Data-centered architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Data-centered architecture is a style in which a central data store (repository or blackboard) is accessed by independent client components that communicate only through it.</mark>

Key points.

  1. In a repository the clients pull data; in a blackboard the store notifies the clients when data of interest changes.
  2. Clients are independent of each other, so they are easy to add or remove.
  3. The central store is a bottleneck and single point of failure; examples are databases, IDEs and speech recognition.

Layered architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>The layered pattern organises the system into ordered layers in which each layer offers services to the layer above and uses only the layer below.</mark>

Diagram.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u2-02" viewBox="0 0 80 338" width="80" height="338" role="img" aria-label="Layers: UI, business logic, data access, database; each uses only the layer below"><style>#dsfig-u2-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u2-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u2-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u2-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u2-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u2-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u2-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u2-02 .t{fill:#16181D;font-weight:500}#dsfig-u2-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u2-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u2-02 .dot{fill:#16181D}#dsfig-u2-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u2-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u2-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u2-02 .ah{fill:#454C5A}#dsfig-u2-02 .ah.hi{fill:#2340B8}#dsfig-u2-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u2-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u2-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u2-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u2-02 .e{stroke:#B1B7C3}html.dark #dsfig-u2-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u2-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u2-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u2-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u2-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u2-02 .t{fill:#E6E8ED}html.dark #dsfig-u2-02 .t.inv{fill:#0F1115}html.dark #dsfig-u2-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u2-02 .dot{fill:#E6E8ED}html.dark #dsfig-u2-02 .ann{fill:#8FA3FF}html.dark #dsfig-u2-02 .lbl{fill:#858D9C}html.dark #dsfig-u2-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u2-02 .ah{fill:#B1B7C3}html.dark #dsfig-u2-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u2-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u2-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u2-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah7" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh7" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M40,59 L40,105" marker-end="url(#ah7)"/><path class="e" d="M40,145 L40,191" marker-end="url(#ah7)"/><path class="e" d="M40,231 L40,277" marker-end="url(#ah7)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">UI</text><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">BL</text><circle class="n" cx="40" cy="212" r="18"/><text class="t" x="40" y="212" dy=".35em" text-anchor="middle">DA</text><circle class="n" cx="40" cy="298" r="18"/><text class="t" x="40" y="298" dy=".35em" text-anchor="middle">DB</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Layers: UI, business logic, data access, database; each uses only the layer below</figcaption></figure>

Key points.

  1. Abstracting common services means placing shared functions such as logging and security in a lower layer, so every upper layer reuses them.
  2. Encapsulation hides each layer's implementation behind its interface, so a layer can change without affecting the others.
  3. An intermediary such as a facade or adapter layer decouples layers, so the upper layer depends on the intermediary and not on the concrete lower layer.
  4. Benefits: portability, modifiability and reuse; limitations: extra overhead, and some changes cross several layers. Examples: OSI model, operating systems.

Asked: [7 marks] (Dec 2024) Describe how the layered pattern makes use of abstract common services, encapsulate and use an intermediary.

Agent-based architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>Agent-based architecture is a style in which a system is built from autonomous agents that perceive their environment, make decisions and cooperate by exchanging messages to achieve goals.</mark>

Key points.

  1. Agents are autonomous, reactive and proactive, and they communicate and coordinate through messages, negotiation and shared protocols.
  2. Pros: it is flexible and decentralised, it scales by adding agents, and it has no single point of failure.
  3. Cons: behaviour is hard to predict, coordination adds complexity and communication overhead, and testing is difficult.
  4. It is suitable for distributed systems when problems are naturally decentralised, such as sensor networks, trading and logistics, but not where strict central control is needed.

Asked: [7 marks] (Jun 2025) Critically evaluate the suitability of agent-based architecture for distributed systems.

Micro-services architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>Microservices architecture structures an application as a collection of small, independently deployable services, each built around one business capability and communicating through lightweight APIs.</mark>

Key points.

  1. Each service owns its code and its database and can be developed, deployed and scaled independently by a small team.
  2. Services communicate through REST/HTTP or messaging queues, usually behind an API gateway.
  3. Each service can use its own language and technology, which gives technology diversity.
  4. Scalability: only the busy service is replicated, for example scaling the checkout service on a sale day, which saves resources compared with cloning the entire application.
  5. Failure is isolated, so one crashing service does not bring the whole system down.
  6. Costs: distributed complexity, network latency, data consistency problems and harder testing.
  7. Agent-based use case: agents are autonomous entities that cooperate to reach goals, whereas microservices are passive, request-driven services, so agents suit decentralised, adaptive problems and microservices suit business applications.
Basis Monolithic Microservices
Structure Single deployable unit Many small independent services
Scalability Scale the whole application Scale each service separately
Deployment Redeploy everything for any change Deploy each service on its own
Coupling Tightly coupled modules Loosely coupled through APIs
Technology One technology stack Different stack per service
Fault tolerance One fault can stop all Fault isolated to a service

Answer frame. For difference questions open with both definitions, then give the table and close with when each fits. For scalability questions define the style, explain decomposition and independent deployment (points 1, 4, 5), give the sale-day example and close with the cost in point 6. For Nov 2022 add a short agent-based definition (point 7 with the agent section).

Asked: [7 marks] (Nov 2022) Explain micro services based architecture and agent based architecture in brief. Asked: [7 marks] (Dec 2025) What is microservices architecture and how is it different from monolithic architecture. Asked: [7 marks] (Jun 2025) Illustrate how the micro-services architecture enhances software scalability.

Reactive architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Reactive architecture builds systems that are responsive, resilient, elastic and message-driven, as stated in the Reactive Manifesto.</mark>

Key points.

  1. Responsive means it answers quickly and consistently; resilient means it stays responsive despite failures.
  2. Elastic means it scales up and down with load, and message-driven means components communicate asynchronously and without blocking.
  3. Examples are event-driven systems, Akka and RxJava.

Representational state transfer architecture

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>REST is an architectural style for distributed hypermedia systems in which everything is a resource identified by a URI and manipulated through a uniform interface using representations; an API that follows its constraints is RESTful.</mark>

Key points.

  1. Client-server: the client handles the interface and the server handles data and logic, so both evolve independently.
  2. Stateless: each request carries all the information needed, so the server stores no client session and scales easily.
  3. Cacheable: responses are marked cacheable or not, which reduces load and latency.
  4. Uniform interface: resources are identified by URIs and manipulated by representations (JSON, XML) with standard HTTP verbs GET, POST, PUT, DELETE, in self-descriptive messages.
  5. Layered system: the client cannot tell whether it talks to the server or an intermediary such as a proxy or load balancer.
  6. Code on demand (optional): the server can send executable code such as JavaScript to extend the client.
  7. Use in web services: REST APIs expose resources over HTTP, giving scalability and interoperability across languages and platforms.

Answer frame. Open by defining REST and RESTful API; list the six constraints in the order above with a sentence each, marking code on demand as optional; add one example such as GET /students/5; close with scalability and interoperability benefits.

Asked: [7 marks] (Nov 2023, Dec 2025) What are the Architectural Constraints of RESTful API? Explain. What is Representational State Transfer (REST) architecture? How is it used in web services?

Last-minute revision

  • A structural model shows static components, a framework model a reusable domain skeleton, a dynamic model run-time behaviour.
  • Pipes and filters: filters transform, pipes carry data, incremental one-way flow; examples UNIX pipes and compilers.
  • Call and return: main program and subroutines, RPC and object-oriented; gives modularity and reuse.
  • Data-centered: clients share a central repository or blackboard.
  • Layered: each layer uses only the layer below; abstraction of common services, encapsulation, intermediary.
  • Agent-based: autonomous cooperating agents, flexible but complex.
  • Microservices: small independent services, own database, scaled individually.
  • Monolith is one deployable unit; microservices give independent deployment and technology diversity.
  • Reactive: responsive, resilient, elastic, message-driven.
  • REST constraints: client-server, stateless, cacheable, uniform interface, layered system, code on demand (optional).
  • REST verbs: GET, POST, PUT, DELETE on URI-identified resources.

Memory hooks

  • Pipes and filters: "pipe carries, filter changes" like a coffee filter.
  • REST constraints: CS-CUL-C, Client-server, Stateless, Cacheable, Uniform, Layered, Code on demand.
  • Reactive: RERM, Responsive, Elastic, Resilient, Message-driven.
  • Layered: think of a cake, each layer touches only its neighbour below.
  • Microservices: many small shops in a mall, each one has its own till.

Coverage checklist

  • structural models: Dec 2024 compare structural, framework and dynamic models.
  • framework models: covered with structural models.
  • dynamic models: covered with structural models.
  • process models: definition and points.
  • dataflow architecture: definition plus the comparative study of styles (Dec 2020, Nov 2022, Jun 2025).
  • pipes and filters architecture: Dec 2020, Nov 2022, Nov 2023.
  • call-and return architecture: Dec 2024.
  • data-centered architecture: definition and points.
  • layered architecture: Dec 2024.
  • agent based architecture: Jun 2025, Nov 2022 (with microservices).
  • Micro-services architecture: Nov 2022, Jun 2025, Dec 2025.
  • Reactive Architecture: definition and points.
  • Representational state transfer architecture: Nov 2023, Dec 2025.
Go to where you left off?

Quick Add to Notes

Save questions, your own notes and screenshots into notes filed by unit. It takes a free account.

Create free account

Have an account? Log in