DI-322 Web Technologies Lecture 06: Web services with SOAP, REST and JSON
DI-322 Web Technologies
0% Completed

Lecture 06: Web services with SOAP, REST and JSON

Outcomes and readiness

You can compare SOAP messaging with REST constraints, design resource-oriented HTTP operations, and validate JSON types. Readiness: explain method, status, header, body, and XML well-formedness.

Motivating problem

A mobile client needs course data; an enterprise partner needs a formal XML message contract. Both are web-service cases, but the best interface may differ.

Models

SOAP defines an XML-based messaging framework with an envelope, optional header, and body; related specifications can add formal contracts and enterprise features. REST is an architectural style: resources are identified, messages use a uniform interface, requests are self-descriptive, and interactions are stateless at the protocol/application boundary. An API using JSON over HTTP is not automatically RESTful. JSON represents objects, arrays, strings, numbers, booleans, and null; it has no comments and requires double-quoted member names.

GET /api/courses/DI-322 HTTP/1.1
Host: api.example
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"code":"DI-322","credits":3}

Worked design

To create a submission, POST /api/submissions with a representation is clearer than GET /api/doCreateSubmission. Success can return 201 Created and a Location for the new resource. Repeating an identical GET should not change server state. A PUT operation is intended to be idempotent; POST is not generally idempotent.

Faded example

Choose a response for missing course DI-999. Hint 1: distinguish malformed request from absent resource. Hint 2: use standard semantics. Solution: 404 Not Found with a safe problem representation; do not return 200 with a hidden error string.

SOAP contrast

A SOAP message places application content inside <soap:Envelope><soap:Body>...</soap:Body></soap:Envelope>. SOAP can be transported over HTTP, but SOAP actions and HTTP operations are distinct layers. Do not claim SOAP means “stateful” or REST means “JSON only.”

Common mistakes

  • URL nouns alone do not establish REST; behavior and constraints matter.
  • JSON number 3 differs from JSON string "3".
  • 200 for every outcome hides protocol meaning and complicates clients.

Practical – DI322-LAB06

Specify a course API with list, detail, create, update, and delete operations. For each, give method, path, request body, success status, one error status, and a JSON example. Then wrap one equivalent lookup request in a minimal SOAP envelope for comparison.

Independent check

  • Q1: SOAP’s root container? Answer: Envelope.
  • Q2: Which is normally safe: GET or POST? Answer: GET.
  • Q3: Is {code:'DI-322'} valid JSON? Answer: no; member name and string require double quotes.

Homework – DI322-A06-H1

Critique an API that uses GET /delete?id=7, returns 200 for missing records, and stores server session state for every request. Propose repairs and trade-offs. Rubric: identify three issues 3, corrected interface 3, status reasoning 2, REST constraint/trade-off 2.

Revision

SOAP is a message framework; REST is an architectural style; JSON is a data format. They answer different questions.

PreviousNext