WEB / WEB-17.01

API contracts, endpoints, and REST

An endpoint is more than a URL: method, representation, status, and operation semantics form a contract. Separate REST architecture from common JSON API conventions.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

GET JSON

Choose contract
The client prepared GET /api/notes/tea with Accept: application/json. This is public-read intent; the endpoint has not received it and the client has no response.
Duru / Client
GET /api/notes/tea; Accept: application/json ready
API endpoint
No request
Resource owner
No selection
Client contract
No validation
Request arrived
The endpoint received method/target and Accept; resource selection and representation policy are not yet complete.
Duru / Client
Waiting response
API endpoint
GET /api/notes/tea received
Resource owner
No selection
Client contract
No validation
Select resource
The logical note is selected from its fixed public owner; a resource is not identical to one JSON byte string.
Duru / Client
Waiting response
API endpoint
GET /api/notes/tea received
Resource owner
Selected public tea note
Client contract
No validation
Media and status
The server prepared 200 application/json for the public note: id=tea, title=Tea note and a links array. This JSON representation has 80 UTF-8 octets; the client has not received it.
Duru / Client
Waiting response
API endpoint
200 JSON ready
Resource owner
Selected public tea note
Client contract
No validation
Response arrived
The client has now received the selected response; prepared and received representations are different stages.
Duru / Client
200 JSON received
API endpoint
200 JSON ready
Resource owner
Selected public tea note
Client contract
No validation
Contract check
The client locally parses received JSON and checks string id/title plus an array links. The selected normal body matches this shape; HTTP 200 alone proves neither this outcome nor resource permission.
Duru / Client
200 JSON received
API endpoint
200 JSON ready
Resource owner
Selected public tea note
Client contract
id/title strings; links array

HEAD metadata

Choose contract
The client prepared HEAD /api/notes/tea with Accept: application/json. This is public-read intent; the endpoint has not received it and the client has no response.
Duru / Client
HEAD /api/notes/tea; Accept: application/json ready
API endpoint
No request
Resource owner
No selection
Client contract
No validation
Request arrived
The endpoint received method/target and Accept; resource selection and representation policy are not yet complete.
Duru / Client
Waiting response
API endpoint
HEAD /api/notes/tea received
Resource owner
No selection
Client contract
No validation
Select resource
The logical note is selected from its fixed public owner; a resource is not identical to one JSON byte string.
Duru / Client
Waiting response
API endpoint
HEAD /api/notes/tea received
Resource owner
Selected public tea note
Client contract
No validation
Media and status
The server prepared 200 and Content-Length: 80 metadata for HEAD with no response content. The length refers to the corresponding JSON GET representation; the client has not received it.
Duru / Client
Waiting response
API endpoint
200 HEAD ready
Resource owner
Selected public tea note
Client contract
No validation
Response arrived
The client has now received the selected response; prepared and received representations are different stages.
Duru / Client
200 HEAD; 0 content
API endpoint
200 HEAD ready
Resource owner
Selected public tea note
Client contract
No validation
Contract check
The client evaluates HEAD metadata: Content-Length: 80 differs from zero content octets. No body is available for JSON parsing; this result does not establish an empty note.
Duru / Client
200 HEAD; 0 content
API endpoint
200 HEAD ready
Resource owner
Selected public tea note
Client contract
Metadata only; no JSON parse

Media refusal

Choose contract
The client prepared GET /api/notes/tea with Accept: image/png. This is public-read intent; the endpoint has not received it and the client has no response.
Duru / Client
GET /api/notes/tea; Accept: image/png ready
API endpoint
No request
Resource owner
No selection
Client contract
No validation
Request arrived
The endpoint received method/target and Accept; resource selection and representation policy are not yet complete.
Duru / Client
Waiting response
API endpoint
GET /api/notes/tea received
Resource owner
No selection
Client contract
No validation
Select resource
The logical note is selected from its fixed public owner; a resource is not identical to one JSON byte string.
Duru / Client
Waiting response
API endpoint
GET /api/notes/tea received
Resource owner
Selected public tea note
Client contract
No validation
Media and status
Accept: image/png is outside this profile’s JSON/plain media set. The server prepares a 406 refusal here; HTTP does not require this choice for every media mismatch.
Duru / Client
Waiting response
API endpoint
406 ready
Resource owner
Selected public tea note
Client contract
No validation
Response arrived
The client has now received the selected response; prepared and received representations are different stages.
Duru / Client
406 received
API endpoint
406 ready
Resource owner
Selected public tea note
Client contract
No validation
Contract check
The client interprets received 406 as this contract’s expected media refusal. It does not establish the normal note’s JSON shape; method support, media selection and resource permission remain separate questions.
Duru / Client
406 received
API endpoint
406 ready
Resource owner
Selected public tea note
Client contract
Expected media refusal

Follow note link

Choose entry
The client knows the documented entry target /api; the note target will be selected from a response relation.
Duru / Client
GET /api ready; note target unknown
API endpoint
No request
Resource owner
Public note ready
Client contract
No relation
Entry request
The endpoint received the public entry GET and can prepare a representation containing the known note relation.
Duru / Client
Waiting entry
API endpoint
GET /api received
Resource owner
Public note ready
Client contract
No relation
Produce relation
The server locally prepares rel=note href=/api/notes/tea; the client has not received that representation yet.
Duru / Client
Waiting entry
API endpoint
Entry links ready
Resource owner
Public note ready
Client contract
No relation
Entry arrived
The client received the entry representation and interprets its href only through documented note-relation semantics.
Duru / Client
Entry links received
API endpoint
Entry links ready
Resource owner
Public note ready
Client contract
No relation
Select relation
The client locally selected rel=note in the entry and prepared its next GET with href=/api/notes/tea. The endpoint has not received this second request; no other target or privileged action is selected.
Duru / Client
Entry received; GET /api/notes/tea ready
API endpoint
Entry links ready
Resource owner
Public note ready
Client contract
note → /api/notes/tea
Linked request
The endpoint received the benign GET target matching the entry href; this independent request needs no previous server-session context.
Duru / Client
Entry links received
API endpoint
GET linked note received
Resource owner
Public note ready
Client contract
note → /api/notes/tea
Note response
The server prepares the public note representation; two read interactions do not prove every REST constraint.
Duru / Client
Entry links received
API endpoint
200 note ready
Resource owner
Public note ready
Client contract
note → /api/notes/tea
Note arrived
The client received the linked note response; the ledger proves target equality without claiming complete REST conformity.
Duru / Client
200 linked note received
API endpoint
200 note ready
Resource owner
Public note ready
Client contract
note → /api/notes/tea

ACTORS · STATE · DATA FLOW

An API is an interaction contract

An API describes operations/data one component exposes to another; not every API runs over the web. A Web API makes that interaction accessible through a web protocol. Atlas GET /api/notes/tea selects a read operation through method and target together. Adding api to a URL or returning JSON does not define the complete contract. Allowed methods, headers, representation shape, and error meaning matter too.

The resource is the logical tea note; its representation is the transferred bytes and metadata about it. One resource is expressed as application/json or text/plain. The JSON contract defines string id/title fields and a links array, while plain supplies Tea note. The client checks HTTP status, Content-Type, and expected shape separately. A 200 and parseable JSON do not make incorrect field types valid. An endpoint need not directly identify a database table or disk file.

GET reads a representation of this public resource; HEAD gives selected metadata without content. POST receives 405 with Allow: GET, HEAD at this read-only endpoint. Safe GET semantics mean the request does not ask for state change, although incidental logging can occur. Safe/idempotent classification does not implement object authorization. The fixture reads a public catalog with no identity. Write APIs need separately defined operation and persistence outcomes.

REST constraints, representations, and hypermedia

REST is Fielding architectural style: client-server, stateless interaction, cache constraints, uniform interface, and layered system work together; code-on-demand is optional. Uniform interface includes resource identification, manipulation through representations, self-descriptive messages, and hypermedia guiding application state. JSON and CRUD resemblance alone do not establish all these constraints.

A stateless interaction carries the context needed to understand each request in that request, without depending on stored client-session context from earlier interactions. It does not forbid server resource data, databases, or caches. Common JSON APIs can use server-side sessions, but that design is different from strict REST statelessness. Evaluate HTTP protocol semantics separately from application session design.

The entry representation at /api returns rel=note and href=/api/notes/tea; the client reads that documented relation and GETs the public target. Following a link makes hypermedia concrete without proving an entire API REST-conformant. Accept: text/plain selects an alternate representation. The fixture selects 406 for image/png, but HTTP does not require every origin to return 406 for every negotiation mismatch. Read status, shape, and supported-media contracts together.

Read every scenario without motion

Shape mismatch

The API consumer contract was read
The public tea note contract requires id:string, title:string and links:array. JSON parsing and matching a consumer’s expected shape are different conditions.
API contract record
Contract: id string
Contract gate review
Candidate not reviewed
Consumer boundary
Consumer not accepted
The candidate representation was selected
The invalidCandidate has id=7, title=Tea note and links=[]. It is a supplied candidate for evaluation; there is no record that the endpoint sent this body.
API contract record
Candidate: id=7
Contract gate review
Served=false
Consumer boundary
Consumer pending
The parser result did not become authority
parseable=true shows readable JSON syntax. Because id is a number, the contract requiring a string is not satisfied.
API contract record
Parseable=true
Contract gate review
id type: number
Consumer boundary
Shape result pending
A mismatch was found at the shape gate
schemaValid=false is a known contract mismatch. Neither an HTTP status nor an application/json label corrects the id field’s type.
API contract record
Parseable=true
Contract gate review
Schema valid=false
Consumer boundary
Not an accepted representation
No actual-response claim was made
The servedByNativeEndpoint=false boundary is preserved. Reporting this candidate as a live endpoint fault or captured malformed response would expand the evidence.
API contract record
Candidate known
Contract gate review
Contract mismatch known
Consumer boundary
No endpoint-incident evidence
Contract and permission remained separate
Shape validation constrains consumer data expectations but grants no resource permission. This review concerns a public-note contract, not access to other objects.
API contract record
Shape gate required
Contract gate review
Permission separate question
Consumer boundary
Consumer acceptance withheld

Method boundary

The endpoint method list was read
/api/notes/tea defines only GET and HEAD. An existing resource path does not mean every HTTP method is supported at that target.
API contract record
Allowed: GET, HEAD
Contract gate review
Method decision pending
Consumer boundary
Permission unknown
The method-mismatch record was selected
The methodMismatch row declares status=405 and Allow=GET, HEAD for POST. Review reads this fixed decision record without sending a new request.
API contract record
Method: POST
Contract gate review
Expected: 405
Consumer boundary
Permission unknown
Method support became the rejection cause
405 explains that the target does not support this method. This record contains no successful actor authentication or object-authorization result.
API contract record
POST unsupported
Contract gate review
Allow: GET, HEAD
Consumer boundary
No authority conclusion
The Allow field was not read as a grant
Allow=GET, HEAD describes supported methods. It does not mean the actor can read every resource using them or has passed application policy.
API contract record
Method capabilities
Contract gate review
Allow ≠ permission
Consumer boundary
Resource policy separate
Media negotiation was treated as a different decision
The negotiation record requesting image/png has status 406. This is the example’s refusal policy, not a requirement for every server to return 406 for that Accept value.
API contract record
Method: 405
Contract gate review
Selected negotiation: 406
Consumer boundary
Denial causes differ
The response decision retained its scope
Method support, representation selection and permission are different gates. One status field cannot prove success or failure of the other two layers.
API contract record
Method gate known
Contract gate review
Representation policy separate
Consumer boundary
No permission outcome

ASSUMPTION · BOUNDARY · CONTROL

Compare the contract with the observed result

Review a controlled public endpoint by method/target, selected media type, status, and schema. A numeric JSON id at /api/notes/tea violates the contract despite successful parsing. A client predicate evaluates this supplied harmless candidate; no malformed protocol or attack response is generated from a production server. Possible effects include a wrong application branch or an unusable typed result. Separate transport success from application-contract validation.

405 describes GET/HEAD support, not permission. An external 404 alone also cannot distinguish resource absence from deliberate concealment. These identity questions are outside the public fixture. Explicit review scope prevents the overclaim that a responsive endpoint proves its entire operation correct. Associate content and metadata with the intended resource and selected representation.

REST labels and state dependencies

A JSON API labeled REST requires more than resource URLs. If understanding a request requires stored server context from an earlier client interaction, strict statelessness needs a different assessment. That alone is neither a vulnerability nor an unusable product; it is a distinction between an architectural claim and behavior. Keeping domain data in a database is not the same session dependency.

Hypermedia relation semantics and representation contracts help clients understand subsequent transitions. An href field alone does not prove complete HATEOAS architecture; how the consumer interprets it matters. The entry-follow case uses only the documented note relation, without arbitrary targets, external links, or privileged operations. The defensive control is an explicit connection between a supported relation and its permitted read operation.

Read every scenario without motion

HEAD byte evidence

The GET representation record was selected
The normal JSON body has contentOctets=80. The same public resource’s text/plain representation is Tea note at 8 bytes; byte count depends on representation.
HTTP observation
JSON: 80 bytes
Context comparison
Plain: 8 bytes
Review conclusion
HEAD not reviewed
The HEAD observation record was read
The HEAD record has status=200, declaredLength=80 and contentOctets=0. Metadata and content carried in this response are separate fields.
HTTP observation
HEAD status=200
Context comparison
Declared length=80
Review conclusion
Content octets=0
Zero content did not mean an empty resource
HEAD has contentOctets=0 because its response carries no content. That zero does not establish an empty GET representation or a missing storage record.
HTTP observation
HEAD: no content
Context comparison
GET representation: 80
Review conclusion
No empty-resource inference
The comparison tuple was completed
Method, media type, status, declared length and carried content count are read together. The 80- and 8-byte results for different media types are not contradictory measurements of one body.
HTTP observation
Method/media linkage required
Context comparison
Metadata ≠ content
Review conclusion
Different representations
No database outcome was assumed
restBoundary declares databaseExecuted=false. No database query or persistent write is inferred from the HTTP byte record.
HTTP observation
HTTP measurements known
Context comparison
Database executed=false
Review conclusion
No storage claim
The review conclusion was bound to representation
This record explains HEAD semantics and byte distinctions. Content delivery, DOM rendering or other media-negotiation conditions need separate observations.
HTTP observation
HEAD content=0
Context comparison
GET JSON length=80
Review conclusion
Render outcome unknown

Link relation

The entry representation was reviewed
The /api entry record contains a link with rel=note and href=/api/notes/tea. This relation is representation data for selecting the next documented target.
HTTP observation
Entry: /api
Context comparison
rel=note
Review conclusion
Next target pending
Relation selection was bound to the record
followedRelation=note matches the entry link. Review reads this ordinary relation without creating another URL or actor permission.
HTTP observation
Followed relation=note
Context comparison
href=/api/notes/tea
Review conclusion
No permission grant
The next target was matched
nextTarget=/api/notes/tea equals the selected href. This documented transition shows target selection from a link relation, not actual request receipt or DOM outcome.
HTTP observation
Relation match known
Context comparison
Next target match known
Review conclusion
No receipt observation
REST scope was assessed separately
completeRestConformanceClaim=false. One link and target match cannot establish implementation of all REST constraints.
HTTP observation
Link transition known
Context comparison
Complete REST claim=false
Review conclusion
Constraint review required
Statelessness and resource state were separated
serverResourceStateAllowed=true and storedPreviousClientSessionContextUsed=false answer different questions. REST statelessness does not mean no resource data can exist on the server.
HTTP observation
Resource state allowed
Context comparison
Previous client context not used
Review conclusion
State types separate
Missing observations did not become a clean result
A selector returning zero matches describes only its supplied observation set. Missing fields or records establish neither contract correctness, REST conformance nor clean runtime behavior.
HTTP observation
Observation set bounded
Context comparison
Missing evidence ≠ clean
Review conclusion
Additional observation required

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Contract ledger and independent predicates

The artifact records GET/HEAD methods, target /api/notes/tea, supported JSON/plain media types, and required id/title/links JSON fields. Normal status=200, media=application/json, and schemaValid=true. A client predicate calculates string id/title and array links separately. It rejects the harmless id=7 candidate; this is a local schema observation, not a real gateway log schema.

The plain GET body Tea note has eight UTF-8 octets; HEAD reports selected JSON representation length while transferring zero content. POST 405 and Allow verify operation support; unsupported image/png 406 is a fixture policy. Negotiation selects from absent/JSON/plain/image-png inputs only, without implementing complete Accept quality/wildcard parsing. Cache behavior and identity decisions are outside this ledger.

Schema selectors and hypermedia evidence

XPath count(/audit/response[@status="200" and @media="application/json" and @schema="invalid"]) counts authored observations pairing successful HTTP with an invalid application shape. The normal valid fixture gives 0 and a supplied positive fixture gives 1. Expected 406/405 responses are separate branches outside this schema condition. With no observation, zero is not proof of clean behavior; response/validation evidence is missing.

Show that the note relation href in the entry document equals the next request target. This is concrete link-follow evidence beyond assuming a hard-coded URL, while still falling short of a complete architectural assessment. Changes to method semantics, media contract, or errors require reconsidering client transitions. Separate a representation prepared by the server from one actually received by the client to preserve result ownership.

Enforce the operation and representation contract

Bind supported methods and media types to dispatch decisions rather than documentation alone. GET and HEAD in this read contract do not initiate business mutation; POST does not enter the selected operation. Safe method semantics do not mean every user may read every resource: private resources require a separate identity and permission decision. The JSON Content-Type must match serialization, and the client validates id/title/links types before use.

A client receiving id=7 must not turn it into a normal note view model merely because status is 200; report a clear contract error. Verify normal JSON/plain separately from unsupported-method/media branches. In link-following, use the documented relation within the expected API scope; not every discovered href is a trusted endpoint. Missing response or validation observations establish neither schema correctness nor access enforcement.

NOW APPLY IT TO THE CASE

Which outcomes are not proved by parsing, method support or a link relation?

Shape, HTTP method, media type and relation are separate fields in the public tea note contract. Review separates candidate data from actual responses and byte metadata from delivery.

Examine the case API contract separately from the representation readable by the browser. Discuss sufficient evidence for envelope, data, errors and resource permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Public-note API contract and relation ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "contract": {
    "resource": "public tea note",
    "target": "/api/notes/tea",
    "allowedMethods": [
      "GET",
      "HEAD"
    ],
    "supportedMediaTypes": [
      "application/json",
      "text/plain"
    ],
    "requiredShape": {
      "id": "string",
      "title": "string",
      "links": "array"
    },
    "selectionScope": [
      "absent Accept",
      "application/json",
      "text/plain",
      "image/png"
    ],
    "fullAcceptParser": false
  },
  "normal": {
    "method": "GET",
    "status": 200,
    "contentType": "application/json",
    "representation": {
      "id": "tea",
      "title": "Tea note",
      "links": [
        {
          "rel": "self",
          "href": "/api/notes/tea"
        }
      ]
    },
    "body": "{\"id\":\"tea\",\"title\":\"Tea note\",\"links\":[{\"rel\":\"self\",\"href\":\"/api/notes/tea\"}]}",
    "contentOctets": 80,
    "schemaValid": true
  },
  "plain": {
    "body": "Tea note",
    "contentOctets": 8,
    "status": 200
  },
  "head": {
    "declaredLength": 80,
    "contentOctets": 0,
    "status": 200
  },
  "methodMismatch": {
    "method": "POST",
    "status": 405,
    "allow": "GET, HEAD"
  },
  "negotiation": {
    "accept": "image/png",
    "status": 406,
    "policy": "selected fixture refusal; not mandatory universal behavior"
  },
  "invalidCandidate": {
    "representation": {
      "id": 7,
      "title": "Tea note",
      "links": []
    },
    "parseable": true,
    "schemaValid": false,
    "servedByNativeEndpoint": false
  },
  "hypermedia": {
    "entryTarget": "/api",
    "entryRepresentation": {
      "links": [
        {
          "rel": "note",
          "href": "/api/notes/tea"
        }
      ]
    },
    "followedRelation": "note",
    "nextTarget": "/api/notes/tea",
    "completeRestConformanceClaim": false
  },
  "restBoundary": {
    "serverResourceStateAllowed": true,
    "storedPreviousClientSessionContextUsed": false,
    "databaseExecuted": false,
    "codeOnDemand": "optional architectural constraint; not executed"
  },
  "selector": {
    "language": "XPath",
    "xml": "<audit><response status=\"200\" media=\"application/json\" schema=\"valid\"/></audit>",
    "xpath": "count(/audit/response[@status=\"200\" and @media=\"application/json\" and @schema=\"invalid\"])",
    "expected": 0,
    "positiveFixtureXml": "<audit><response status=\"200\" media=\"application/json\" schema=\"invalid\"/></audit>",
    "positiveExpected": 1,
    "scope": "Only authored protocol-decision observations, not product log field names or a live HTTP capture.",
    "missingFieldBehavior": "Missing observation is insufficient evidence; zero matches is not proof of correct runtime behavior."
  }
}

contract: Joint definition of method, target, media, shape, and supported operation.
invalidCandidate: Harmless supplied local schema counterexample, not a wire response.
hypermedia: Target selected through an entry relation, without full REST conformity claim.

Read-only public fixture with a shape predicate and limited media selection; no verification of writes, identity, full REST/caching, or a general Accept parser.

Two reality checks

JSON and CRUD endpoints automatically make an API REST.

REST architecture constraints and uniform-interface/hypermedia semantics also matter; JSON is a representation choice.

REST statelessness forbids server databases or resource state.

The constraint excludes requests depending on previous client-interaction context; resource data and databases are different state categories.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

A JSON candidate has id=7, a string title and array links. Is parsability sufficient for schemaValid?

No; selected schemaValid=false and the candidate is not served.
Yes; valid JSON automatically satisfies every API contract.

Read the explained answer

No; selected schemaValid=false and the candidate is not served. — Representation syntax and field-type contracts are different gates; a numeric id is not the expected string.

What is taught by following an entry-representation rel:note link, and what is not guaranteed?

Selected lesson artifact fields; teaching example

hypermedia: {"entryTarget":"/api","entryRepresentation":{"links":[{"rel":"note","href":"/api/notes/tea"}]},"followedRelation":"note","nextTarget":"/api/notes/tea","completeRestConformanceClaim":false}

A JSON endpoint and one link prove the whole system RESTful.
The client discovers an advertised next target; complete REST conformance is not claimed.

Read the explained answer

The client discovers an advertised next target; complete REST conformance is not claimed. — FollowedRelation note and nextTarget are explicit; the example does not measure every architectural constraint.

Why does the REST stateless constraint not prohibit server resource state or a database?

Read the explained answer

Server resource state may be retained; interpreting the selected request does not use stored previous client-session context. The client request must carry necessary context. This fixture has databaseExecuted=false; stateless does not imply a storage-free architecture or public access to every GET.

□ I distinguished resource state from session context.

□ I did not count stateless as a permission grant.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

Roy Fielding — Dissertation Chapter 5: REST5.1.2 Client-Server · 5.1.3 Stateless · 5.1.4 Cache · 5.1.5 Uniform Interface · 5.1.6 Layered System · 5.1.7 Code-On-Demand · 5.2.1.1 Resources and Resource Identifiers · 5.2.1.2 Representations · 5.2.2 Connectors
RFC 9110 — HTTP Semantics3.1 Resources · 3.2 Representations · 8.3 Content-Type · 8.6 Content-Length · 9.2.1 Safe Methods · 9.2.2 Idempotent Methods · 9.3.1 GET · 9.3.2 HEAD · 12.5.1 Accept · 15.5.5 404 Not Found · 15.5.6 405 Method Not Allowed · 15.5.7 406 Not Acceptable
Node.js v24.13.0 — HTTP APIhttp.createServer([options][, requestListener]) · response.end([data[, encoding]][, callback]) · response.writableEnded · response.writableFinished

YOUR NOTES / THIS BROWSER

API contracts, endpoints, and REST

1. Core · Mechanism

GET JSON

HEAD metadata

Media refusal

Follow note link

An API is an interaction contract

REST constraints, representations, and hypermedia

2. Red · Trust & Impact

Shape mismatch

Method boundary

Compare the contract with the observed result

REST labels and state dependencies

3. Blue · Secure development & defense

HEAD byte evidence

Link relation

Contract ledger and independent predicates

Schema selectors and hypermedia evidence

Enforce the operation and representation contract

Which outcomes are not proved by parsing, method support or a link relation?

Two reality checks

A JSON candidate has id=7, a string title and array links. Is parsability sufficient for schemaValid?

What is taught by following an entry-representation rel:note link, and what is not guaranteed?

Why does the REST stateless constraint not prohibit server resource state or a database?

Sources and scope