3 ms·

I don’t think that is a good explanation. > REST is about describing services that you can interact with with no prior knowledge. REST is about completely deco

I don’t think that is a good explanation. > REST is about describing services that you can interact with with no prior knowledge. REST is about completely decoupling the client and server (in terms of prior knowledge) beyond standardized media types (HTML, CSS, JS) The idea that REST is confined to standard media types like HTML and CSS is wrong. It is sufficient that media types are known to specific clients and server, but that does not have to include web browsers or arbitrary clients. Quote [1]: REST provides a hybrid of all three options by focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface. REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types, selected dynamically based on the capabilities or desires of the recipient and the nature of the resource. Whether the representation is in the same format as the raw source, or is derived from the source, remains hidden behind the interface. The benefits of the mobile object style are approximated by sending a representation that consists of instructions in the standard data format of an encapsulated rendering engine (e.g., Java [45]). [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

cxr 3y ago
I don't get what your quibble is. > The idea that REST is confined to standard media types[...] is wrong You sourced the response yourself: > REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types ... and given that you did just copy and paste that part, it leads me to believe that that's not what you've got an issue with. So what do you have an issue with?
- ivan_gammel 3y ago
  „Standard media type” has different meaning in the comment you refer to and in the quote.
  - cxr 3y ago
    This is not a very helpful response.
    - ivan_gammel 3y ago
      You reference a comment that basically says that REST is HTML UI talking to server via links and forms, rather than interaction with JSON or XML-based API. This is not correct, neither according to original dissertation nor according to modern understanding of RMM 3 APIs. API using JSON can support HATEOAS. Standard media type in the sense of REST is not the W3C media type, but anything that both server and client can understand. appilcation/hal+json is a good example.
      - cxr 3y ago
        Nope. Try again. It "basically" says what it says—which is the same thing that the part you quoted from Fielding says—and nowhere does it say that the media type has to be HTML, which is what you (now) seem to be implying (but are unable or unwilling to articulate for some reason).
        ivan_gammel 3y ago
        How exactly do you understand the following quote that is part of what you call a „good explanation“? > REST is about completely decoupling the client and server (in terms of prior knowledge) beyond standardized media types (HTML, CSS, JS)
        cxr 3y ago
        I understand it the way it's written. I don't know what you're looking for here; jcrites is not staying that { HTML, CSS, JS } are prerequisites to REST. They're giving examples of standard media types. If there are other media types for which it is possible to do REST, then those are acceptable, too, of course. But HTML is not a requirement.
      - 3y ago
myk9001 3y ago
You're absolutely correct in stating REST is not confined to HTML, CSS, JS. A JSON, XML, or binary-based media type are all compatible with the architectural style. I don't think the grandparent implies otherwise, though. They are using the browser/HTML example to describe the particular mechanics of client/server interaction, which are key to a REST application. They also bring up "decoupling the client and server (in terms of prior knowledge)". As far as I understand, this isn't about an ability of an arbitrary client to talk to the server. This is, again, easier to explain using the web browser as an example, but the principle equally applies to any client. Think of a "traditional" web application (Django, RoR, etc). Say, one day you decide to completely rewrite it -- add new pages, remove some existing pages, change the site structure (as in which pages the user can navigate to from a given page). While the app has changed beyond recognition, the user doesn't need to download a new version of browser, they can still point their existing browser to the app's home page and it will just work. Now, all of the above should hold for a RESTful app based on a binary media type. I believe, this is the key point of going REST-way. There's a trade-off, of course. While the client is decoupled from the server along one axis, they are fundamentally coupled along another. Imagine a RESTful banking app, and let's say we would like to add a list of recent transactions to the home screen of a mobile client, but the server resource representing the home screen doesn't encode this list in any way. Well, there's is no way to just add it on the client in this case, at least without breaking the principles of REST hence defying the whole purpose of choosing this architectural style in the first place. We have to change the backend code in this case. I can readily see how the limitation described above might be a deal-breaker for a lot of apps as we know them today.

cxr 3y ago

I don't get what your quibble is. > The idea that REST is confined to standard media types[...] is wrong You sourced the response yourself: > REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types ... and given that you did just copy and paste that part, it leads me to believe that that's not what you've got an issue with. So what do you have an issue with?

ivan_gammel 3y ago
„Standard media type” has different meaning in the comment you refer to and in the quote.
- cxr 3y ago
  This is not a very helpful response.
  - ivan_gammel 3y ago
    You reference a comment that basically says that REST is HTML UI talking to server via links and forms, rather than interaction with JSON or XML-based API. This is not correct, neither according to original dissertation nor according to modern understanding of RMM 3 APIs. API using JSON can support HATEOAS. Standard media type in the sense of REST is not the W3C media type, but anything that both server and client can understand. appilcation/hal+json is a good example.
    - cxr 3y ago
      Nope. Try again. It "basically" says what it says—which is the same thing that the part you quoted from Fielding says—and nowhere does it say that the media type has to be HTML, which is what you (now) seem to be implying (but are unable or unwilling to articulate for some reason).
      - ivan_gammel 3y ago
        How exactly do you understand the following quote that is part of what you call a „good explanation“? > REST is about completely decoupling the client and server (in terms of prior knowledge) beyond standardized media types (HTML, CSS, JS)
        cxr 3y ago
        I understand it the way it's written. I don't know what you're looking for here; jcrites is not staying that { HTML, CSS, JS } are prerequisites to REST. They're giving examples of standard media types. If there are other media types for which it is possible to do REST, then those are acceptable, too, of course. But HTML is not a requirement.
    - 3y ago

myk9001 3y ago

You're absolutely correct in stating REST is not confined to HTML, CSS, JS. A JSON, XML, or binary-based media type are all compatible with the architectural style. I don't think the grandparent implies otherwise, though. They are using the browser/HTML example to describe the particular mechanics of client/server interaction, which are key to a REST application. They also bring up "decoupling the client and server (in terms of prior knowledge)". As far as I understand, this isn't about an ability of an arbitrary client to talk to the server. This is, again, easier to explain using the web browser as an example, but the principle equally applies to any client. Think of a "traditional" web application (Django, RoR, etc). Say, one day you decide to completely rewrite it -- add new pages, remove some existing pages, change the site structure (as in which pages the user can navigate to from a given page). While the app has changed beyond recognition, the user doesn't need to download a new version of browser, they can still point their existing browser to the app's home page and it will just work. Now, all of the above should hold for a RESTful app based on a binary media type. I believe, this is the key point of going REST-way. There's a trade-off, of course. While the client is decoupled from the server along one axis, they are fundamentally coupled along another. Imagine a RESTful banking app, and let's say we would like to add a list of recent transactions to the home screen of a mobile client, but the server resource representing the home screen doesn't encode this list in any way. Well, there's is no way to just add it on the client in this case, at least without breaking the principles of REST hence defying the whole purpose of choosing this architectural style in the first place. We have to change the backend code in this case. I can readily see how the limitation described above might be a deal-breaker for a lot of apps as we know them today.