[Translation] REST APIs must be Hypertext-driven

Original article address: Roy T. Fielding: REST APIs must be hypertext-driven

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. today's example is the SocialSite rest api. that is RPC. it screams RPC. there is so much coupling on display that it shoshould be given an X rating.
I am getting increasingly disappointed. Many people call any HTTP-based interface a REST API. The current example is the SocialSite REST API. That is RPC, the real RPC. It is so coupled with the display that the difference is nothing more than this

What needs to be done to make the REST plain tural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a rest api. period. is there some broken manual somewhere that needs to be fixed?
Based on hypertext concepts, how can we ensure a clear REST architecture style? In this case, if the application status engine (API) is not driven by hypertext, it is neither RESTful nor rest api. That's simple. Should I fix some broken REST manuals?

API designers, please note the following rules before calling your creation a rest api:
API designers should pay attention to the following rules before calling REST APIs:

A rest api shoshould not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. in general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.]
REST APIs should not depend on any specific communication protocol. When using a specific protocol, the validity of metadata and the selection of methods may be limited. Generally, when the Protocol element uses a URI as the identifier, it must be allowed to use any URI scheme. [Non-conformity means that the identity and interaction are not separated]

A rest api shocould not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP's PATCH method or Link header field. workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP's method set) shocould be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.]
The rest api should not modify the resources reserved in the communication protocol to supplement or modify the usage of the standard protocol, such as the http patch method and the Link head domain. A scheme that violates this principle should be defined separately, or at least indicated in the appendix, such a scheme will eventually be discarded. [This does not mean that resource interfaces are object-related and not universal]

A rest api shocould spend almost all of its descriptive effort in defining the media type (s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. any effort spent describing what methods to use on what URIs of interest shocould be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types ). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]
REST APIs should focus most of their efforts on defining media types, defining extended link names, and defining standard media types in hypertext tags, to describe resources and operate application states. Any work similar to what method a certain URI should use, all rules should be fully defined in the scope of processing rules for a specific media type (in most cases, existing media types have already been defined ). [This does not mean that interaction is driven by other information, rather than hypertext]

A rest api must not define fixed resource names or hierarchies (an obvious coupling of client and server ). servers must have the freedom to control their own namespace. instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling].
REST APIs cannot define fixed resource names or hierarchies (this is an obvious coupling between the client and the server), and the server must be free to control its own namespace. Like HTML forms and URI templates, the media type and link relationship should be used to indicate how the client constructs a correct URI. [This does not mean that the client is speculating on the resource structure through other information (such as domain-related standards), which is data-oriented, similar to RPC function coupling]

A rest api shoshould never have "typed" resources that are significant to the client. specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client. the only types that are significant to a client are the current representation's media type and standardized relation names. [ditto]
REST APIs cannot use typed resources that are important to the client. The authors of the specification may use resource types to describe the server implementation behind the interface, but these types must be independent of the client and invisible to the client. The only valid type for the client is the current declarative media type and standard Link name. [Same as above]

A rest api shoshould be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (I. e ., expected to be understood by any client that might use the API ). from that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the specified ed representations or implied by the user's manipulation of those representations. the transitions may be determined (or limited by) the client's knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g ., code-on-demand ). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]
To use REST APIs, you only need to know the initial URI (bookmarks) and a series of standard media types for the target user (any client knows the APIs used to operate the media type ). In this way, the status of all applications can be switched in this way: the server provides options in the returned declarative message, which is selected by the client, or it is accompanied by the user's operations on the expressive content. Status transition is determined by the client's understanding of media types and resource communication mechanisms, or by these factors, these problems can be improved based on the actual situation (for example, using the code-on-demand technology such as javascript ). [This does not mean that interaction is driven by other information, rather than hypertext]

There are probably other rules that I am forgetting, but the above are the rules related to the hypertext constraint that are most often violated within so-called REST APIs. please try to adhere to them or choose some other buzzword for your API.
There may be other rules that I cannot remember at the moment, but the so-called REST APIs generally violate the above rules related to hypertext constraints, correct these mistakes or use other titles.

All Program interfaces have specific purposes. Therefore, it may be a request for specific resources or operations, but this becomes an HTTP-based interface that Roy T. Fielding understands.
What are typed resources, resource types, media types, and their differences?
Question 2: How can I obtain specific resources only through the initial URI? What is the form of such a REST API? After all, not all common applications are the same as spider. You just need to step down with root.
In a few days, I will take a closer look at the content of the original article to reply to the discussion.