However, in recent years, a return to REST principles indicates that HTTPwas good
enough after all. Developers are learning these lessons:
??? Most, if not all, domains can be fairly easily modeled as sets of CRUD (create, read,
update, delete) operations. These operations roughly correspond to HTTP POST,
GET, PUT, and DELETE, respectively. In this way, the set of actions is standardized.
??? Names corresponding to resources (/person/123) are generally consistent, robust,
and understandable. Names corresponding to service endpoints (/personService)
tend to be too broad and underspecified, while names corresponding to RPC calls
(/person/show/123, when accessed with GET) are redundant.
??? Orthogonality wins. Names should identify resources; nothing more or less. Success
and failure should be inferred from the HTTPresponse status, not from an
error message within the payload. A resource can have multiple representations,
but they should all be identified as originating from the same resource (and their
names should reflect that).
The combination of nouns, verbs, and content types is often referred to as the REST
triangle. Together, the three corners of the triangle define the architecture. A RESTcentric
design decomposition is often done by deciding on the nouns (identifying and
naming things), selecting a uniform set of verbs (easy if you are using HTTP), and
choosing content types.
Pages:
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292