FIT5225 · Cloud Computing And Security
Web Services and SOA
Once your code runs in containers, it has to talk — this chapter is how services expose and consume each other over the network, and how you structure a system out of them. FIT5225 frames the central contrast as SOAP vs REST: SOAP is a rigid XML protocol with formal contracts; REST is an architectural style built on plain HTTP, usually carrying JSON, and is the modern default for web APIs. You learn the HTTP method semantics that REST relies on — which verbs are safe (read-only) and which are idempotent (repeatable with the same effect), the GET / PUT / DELETE vs POST distinction — and the data-format pair XML vs JSON. The chapter then zooms out to architecture: monolith → SOA → microservices, a move from share-everything to share-nothing, with an API gateway in front. Quizzes test these distinctions and the idempotency of each verb.
What this chapter covers
- 01SOAP vs REST — protocol vs architectural style
- 02HTTP methods & REST constraints — safe, idempotent, stateless
- 03XML vs JSON, and URL vs URI vs URN
- 04SOA principles → microservices — the central diagram
- 05Monolith vs SOA vs Microservices — share-everything to share-nothing
- 06The API gateway's role
Worked example: classify the HTTP verbs by safe and idempotent
GET /orders/42, PUT /orders/42 (replace the order), DELETE /orders/42, and POST /orders (create a new order). (a) Which of these are safe? (b) Which are idempotent? (c) A flaky network makes a client send the same request twice — for which operation is the double-send genuinely dangerous, and why?- +1(a) Safe (read-only, no state change): only GET. PUT, DELETE and POST all change server state, so none of them is safe.
- +2(b) Idempotent (same effect once or many times): GET, PUT and DELETE. Repeating GET returns the same resource; PUT re-sets the same final value; DELETE leaves the resource gone after the first call.
- +1(c) The dangerous double-send is POST — it is not idempotent: each POST /orders creates a new order, so a retry can create a duplicate order.
- +1Conclude / mitigate: because POST is not idempotent, retries need a guard — an idempotency key, or designing the create as an idempotent PUT to a client-chosen ID.
Key terms
- SOAP vs REST
- SOAP is a strict XML messaging protocol with formal contracts (WSDL) and built-in standards — heavyweight but rigorous, used where strong contracts and enterprise features matter. REST is an architectural style over plain HTTP, usually carrying JSON, that is lighter, stateless and the modern default for web APIs. Protocol vs style is the headline distinction.
- Safe method
- An HTTP method that does not change server state — it only reads. GET (and HEAD) are safe; PUT, POST and DELETE are not, because they create, replace or remove resources. Safe methods can be cached and prefetched freely.
- Idempotent method
- An HTTP method that has the same effect whether it is applied once or many times. GET, PUT and DELETE are idempotent; POST is not, because each POST typically creates a new resource. Idempotency is why retrying a failed PUT or DELETE on a flaky network is safe but retrying a POST may duplicate.
- XML vs JSON
- Two data-interchange formats. XML is verbose, tag-based and schema-rich, the native format of SOAP. JSON is lightweight, key/value, native to JavaScript and the usual REST payload. JSON is smaller and faster to parse; XML carries richer formal structure — the quiz pairs them with REST and SOAP respectively.
- Monolith vs SOA vs Microservices
- Three points on a share-everything to share-nothing spectrum. A monolith is one deployable unit sharing one codebase and database. SOA decomposes the system into coarse, reusable services, often over an enterprise bus. Microservices push further: many small, independently deployable services each owning its own data, fronted by an API gateway.
Web Services and SOA FAQ
Is REST 'better' than SOAP?
Not better, different. The exam-safe framing is protocol vs style: SOAP is a rigid XML protocol with formal contracts and enterprise features (security, transactions), preferred where strong, machine-readable contracts matter; REST is a lightweight HTTP style with JSON, stateless and cache-friendly, the default for public web and mobile APIs. State the trade-off rather than declaring a winner.
Why are PUT and DELETE idempotent but POST is not?
Because of what they do to state. PUT replaces a resource with a given value, so doing it again sets the same value — no further change. DELETE removes a resource; after the first call it is already gone, so repeats have no extra effect. POST usually creates a new resource each time, so two POSTs make two resources. That is why retrying POST on a flaky network can duplicate, while retrying PUT or DELETE is safe.
What's the difference between a URL, a URI and a URN?
A URI (Uniform Resource Identifier) is the general identifier; a URL is a URI that also tells you how to locate the resource (the scheme + address, like https://...); a URN names a resource without saying where to find it. So URL and URN are both kinds of URI: URI is the superset.
When do I choose microservices over a monolith?
When independent scaling, independent deployment and team autonomy outweigh the added operational complexity. A monolith is simpler to build, test and deploy when small. Microservices let each service scale and ship on its own and own its own data, at the cost of distributed-system overhead (networking, observability, consistency). SOA sits between, decomposing into coarser, reusable services.
Exam move
Make the SOAP-vs-REST table reflexive: protocol vs style, XML vs JSON, strict contract vs lightweight HTTP, stateful contract vs stateless. The highest-frequency calculation-style question is classifying HTTP verbs, so build the safe/idempotent grid cold — GET is the only safe verb; GET, PUT and DELETE are idempotent; POST is neither — and be able to explain why each lands where it does, plus the retry consequence (POST can duplicate). Know URL ⊆ URI and URN as a quick trap. For architecture, place monolith, SOA and microservices on the share-everything to share-nothing line and name the API gateway's job. These are pure-distinction marks — the cheapest in the unit if you drill the tables.
