Loading ...
Sorry, an error occurred while loading the content.
 

Is there (a need for) a text/form+html media type?

Expand Messages
  • Jakob Strauch
    In some posts here it is mentioned, one can use simple html forms for providing a decoupled POST/PUT mechanismen. (and thus also avoiding communicating
    Message 1 of 16 , Aug 3, 2011
      In some posts here it is mentioned, one can use simple html forms for providing a decoupled POST/PUT mechanismen. (and thus also avoiding communicating UriTemplates)

      I was wondering, if a there is a specific media type for that? Ye, sure one can use just text/html. But to support better visibility, i could imagine a media type text/form+html, that would better communicate the intend...

      Am i missing something? Is there related work?
    • Jason Erickson
      It already exists, if I understand your question, except it is application/x-www-form-urlencoded.
      Message 2 of 16 , Aug 3, 2011
        It already exists, if I understand your question, except it is application/x-www-form-urlencoded.
      • Jakob Strauch
        ... This is for submitting concrete data to a server. What i meant is the step before that: telling the client dynamically, how to create or update a resource.
        Message 3 of 16 , Aug 3, 2011
          --- In rest-discuss@yahoogroups.com, Jason Erickson <jason@...> wrote:
          >
          > It already exists, if I understand your question, except it is application/x-www-form-urlencoded.
          >

          This is for submitting concrete data to a server. What i meant is the step before that: telling the client dynamically, how to create or update a resource. This is what a html form usually does for a web browser...
        • Mike Kelly
          ... What could an intermediary do with this greater visibility?
          Message 4 of 16 , Aug 3, 2011
            On Wed, Aug 3, 2011 at 9:56 PM, Jakob Strauch <jakob.strauch@...> wrote:
            But to support better visibility, i could imagine a media type text/form+html, that would better communicate the intend...

            What could an intermediary do with this greater visibility?
          • Jason Erickson
            ... So you want a media type that says, I am valid HTML but I only contain form elements ? Why do you need that when you can use text/html to return HTML
            Message 5 of 16 , Aug 3, 2011
              >
              > It already exists, if I understand your question, except it is application/x-www-form-urlencoded.
              >

              This is for submitting concrete data to a server. What i meant is the step before that: telling the client dynamically, how to create or update a resource. This is what a html form usually does for a web browser...

              So you want a media type that says, "I am valid HTML but I only contain form elements"? Why do you need that when you can use text/html to  return HTML that only contains form elements and the client could see that.  For it to be useful, there must exist clients that Accept text/form+html but not text/html, which seems odd to me.  (If it can accept text/html, then it would be able to recognize form stuff, too.)  

              I think I must be fundamentally misunderstanding the problem you are trying to address.

            • Jakob Strauch
              ... Maybe i misunderstood something, but text/form+html implies, that is a valid html document, too. Like atom+xml is a valid xml file. We use atom+xml for
              Message 6 of 16 , Aug 4, 2011
                > For it to be useful, there must exist clients that Accept text/form+html but not text/html, which seems odd to me. (If it can accept text/html, then it would be able to recognize form stuff, too.)

                Maybe i misunderstood something, but text/form+html implies, that is a valid html document, too. Like atom+xml is a valid xml file. We use atom+xml for feeds and not plain xml. The intention of svg+xml is also clear.

                I think the benefit lies on both sides of the network, where i can easly map my media types with my internal representations (e.g. objects).

                Has the "+" symbol a defined semantic or is it just an convention?
              • Jakob Strauch
                ... I don´t know. What does an intermediary do with atom+xml instead of xml ...? By the way: what are intermediaries actual doing except caching and load
                Message 7 of 16 , Aug 4, 2011
                  --- In rest-discuss@yahoogroups.com, Mike Kelly <mike@...> wrote:
                  >
                  > On Wed, Aug 3, 2011 at 9:56 PM, Jakob Strauch <jakob.strauch@...> wrote:
                  >
                  > > But to support better visibility, i could imagine a media type
                  > > text/form+html, that would better communicate the intend...
                  > >
                  >
                  > What could an intermediary do with this greater visibility?
                  >

                  I don´t know. What does an intermediary do with "atom+xml" instead of "xml"...?

                  By the way: what are intermediaries actual doing except caching and load balancing?

                  I thought the media type is primary used for client/server interaction and secondary for the intermediaries...
                • Will Hartung
                  On Thu, Aug 4, 2011 at 11:00 AM, Jakob Strauch wrote: ** ... Intermediaries ARE clients, just not YOUR client. Who knows what they re
                  Message 8 of 16 , Aug 4, 2011
                    On Thu, Aug 4, 2011 at 11:00 AM, Jakob Strauch <jakob.strauch@...> wrote:

                    I don´t know. What does an intermediary do with "atom+xml" instead of "xml"...?

                    By the way: what are intermediaries actual doing except caching and load balancing?

                    I thought the media type is primary used for client/server interaction and secondary for the intermediaries...

                    Intermediaries ARE clients, just not YOUR client. Who knows what they're doing. Your server can't tell the difference.

                    The point being made, one that Eric brings up often, is that when you use media types that are intermediary friendly, you likely get better value in the long term.

                    For example, an intermediary cache/proxy may well simply ignore and pass through media types that it doesn't know, and give no value whatsoever (such as caching).

                    So, when working with the vast, wild Internet at large, it's better to use media types that the Internet in the large is familiar with.

                    Regards,

                    Will Hartung
                    (willh@...)

                  • Jakob Strauch
                    ... I know, but what if I care less about intermediaries (think about securing representations - e.g. by https - it will eliminate intermediate caching
                    Message 9 of 16 , Aug 4, 2011
                      > Intermediaries ARE clients, just not YOUR client. Who knows what they're
                      > doing. Your server can't tell the difference.

                      I know, but what if I care less about intermediaries (think about securing representations - e.g. by https - it will eliminate intermediate caching efforts).

                      I think there is much more (business) value in concentrating on things like hypermedia, integration and interoperability (serendipitous use).
                    • Mike Kelly
                      ... How would creating an additional media type for html forms help with any of that? Cheers, Mike
                      Message 10 of 16 , Aug 4, 2011
                        On Thu, Aug 4, 2011 at 7:41 PM, Jakob Strauch <jakob.strauch@...> wrote:

                        > Intermediaries ARE clients, just not YOUR client. Who knows what they're
                        > doing. Your server can't tell the difference.

                        I know, but what if I care less about intermediaries (think about securing representations - e.g. by https - it will eliminate intermediate caching efforts).

                        I think there is much more (business) value in concentrating on things like hypermedia, integration and interoperability (serendipitous use).

                        How would creating an additional media type for html forms help with any of that?

                        Cheers,
                        Mike
                         
                      • Nathan
                        ... The +xml suffix is standardized under RFC 3023 and signal s that a media type can be processed by general XML tooling. Other suffixes have not been
                        Message 11 of 16 , Aug 4, 2011
                          Jakob Strauch wrote:
                          >> For it to be useful, there must exist clients that Accept text/form+html but not text/html, which seems odd to me. (If it can accept text/html, then it would be able to recognize form stuff, too.)
                          >
                          > Maybe i misunderstood something, but text/form+html implies, that is a valid html document, too. Like atom+xml is a valid xml file. We use atom+xml for feeds and not plain xml. The intention of svg+xml is also clear.
                          >
                          > I think the benefit lies on both sides of the network, where i can easly map my media types with my internal representations (e.g. objects).
                          >
                          > Has the "+" symbol a defined semantic or is it just an convention?

                          The +xml suffix is standardized under RFC 3023 and signal's that a media
                          type can be processed by general XML tooling.

                          Other suffixes have not been standardized though, and are more of a
                          convention; however earlier in the year discussion over standardizing
                          +json was taking place between Ned Freed and Larry Masinter IIRC.

                          Best,

                          Nathan
                        • Eric J. Bowman
                          ... Knows to call its Atom processor instead of a raw XML parser. But, the issue here is really, why does the use of forms need to be communicated over the
                          Message 12 of 16 , Aug 8, 2011
                            "Jakob Strauch" wrote:
                            >
                            > >
                            > > > But to support better visibility, i could imagine a media type
                            > > > text/form+html, that would better communicate the intend...
                            > > >
                            > >
                            > > What could an intermediary do with this greater visibility?
                            > >
                            >
                            > I don´t know. What does an intermediary do with "atom+xml" instead of
                            > "xml"...?
                            >

                            Knows to call its Atom processor instead of a raw XML parser. But, the
                            issue here is really, why does the use of forms need to be communicated
                            over the wire? In the case of XForms, application/xhtml+xml is used,
                            and the document's hypertext turns on the XForms processor (if present).
                            But that processor won't be called unless the client knows how to
                            process XHTML as such, which is all the granularity which needs to go
                            over the wire at the protocol layer. Nothing wrong with fine-grained
                            conformance levels / versioning within the representation, so long as
                            the proper coarse-grained processing model is called.

                            >
                            > By the way: what are intermediaries actual doing except caching and
                            > load balancing?
                            >

                            Antivirus gateways, transcoding proxies for wireless networks, DNS
                            precache, ISP Web accelerators (image modification) -- all those things
                            which make the Web anarchically scalable. All you can do is stick to
                            standardized semantics, thereby supporting all those things which never
                            occurred to you.

                            >
                            > I thought the media type is primary used for client/server
                            > interaction and secondary for the intermediaries...
                            >

                            See REST Chapter 6.5.2, the point of the style is "standard semantics
                            which can be interpreted by intermediaries almost as well as by the
                            machines that originate [or consume*] services". This is primarily
                            achieved by exposing the sender's intended processing model for the
                            representation, as a media type.

                            -Eric

                            *another edit for RESTbis...
                          • Eric J. Bowman
                            ... Then what is your interest in REST? You can design an outhouse as a gazebo, but functionally, it would lack the required privacy. ... I have to pay for
                            Message 13 of 16 , Aug 8, 2011
                              "Jakob Strauch" wrote:
                              >
                              > > Intermediaries ARE clients, just not YOUR client. Who knows what
                              > > they're doing. Your server can't tell the difference.
                              >
                              > I know, but what if I care less about intermediaries (think about
                              > securing representations - e.g. by https - it will eliminate
                              > intermediate caching efforts).
                              >

                              Then what is your interest in REST? You can design an outhouse as a
                              gazebo, but functionally, it would lack the required privacy.

                              >
                              > I think there is much more (business) value in concentrating on
                              > things like hypermedia, integration and interoperability
                              > (serendipitous use).
                              >

                              I have to pay for bandwidth at the origin server, while maximizing
                              user-perceived performance, so I see plenty of business value in a
                              generic interface which allows intermediaries I don't know about (and
                              which don't know about my system) to scale my system for me.

                              -Eric
                            • Jakob Strauch
                              Thank you all for your comments. I think my misleading assumption was, that a client can be dynamically tought by the server to construct a message by sending
                              Message 14 of 16 , Aug 8, 2011
                                Thank you all for your comments. I think my misleading assumption was, that a client can be dynamically tought by the server to construct a message by sending a HTML Form.

                                While a real user would know from the web application context, where to place his name and adress, how could a machine do that?


                                --- In rest-discuss@yahoogroups.com, "Eric J. Bowman" <eric@...> wrote:
                                >
                                > "Jakob Strauch" wrote:
                                > >
                                > > > Intermediaries ARE clients, just not YOUR client. Who knows what
                                > > > they're doing. Your server can't tell the difference.
                                > >
                                > > I know, but what if I care less about intermediaries (think about
                                > > securing representations - e.g. by https - it will eliminate
                                > > intermediate caching efforts).
                                > >
                                >
                                > Then what is your interest in REST? You can design an outhouse as a
                                > gazebo, but functionally, it would lack the required privacy.
                                >
                                > >
                                > > I think there is much more (business) value in concentrating on
                                > > things like hypermedia, integration and interoperability
                                > > (serendipitous use).
                                > >
                                >
                                > I have to pay for bandwidth at the origin server, while maximizing
                                > user-perceived performance, so I see plenty of business value in a
                                > generic interface which allows intermediaries I don't know about (and
                                > which don't know about my system) to scale my system for me.
                                >
                                > -Eric
                                >
                              • Will Hartung
                                ... It s a prevalent misconception, that somehow REST clients are partially sentient and able to intuit data simply from a payload format. The harsh truth is
                                Message 15 of 16 , Aug 9, 2011
                                  On Mon, Aug 8, 2011 at 11:56 PM, Jakob Strauch <jakob.strauch@...> wrote:
                                   

                                  Thank you all for your comments. I think my misleading assumption was, that a client can be dynamically tought by the server to construct a message by sending a HTML Form.

                                  While a real user would know from the web application context, where to place his name and adress, how could a machine do that?

                                  It's a prevalent misconception, that somehow REST clients are partially sentient and able to intuit data simply from a payload format. The harsh truth is that clients, and not just machine clients but even human ones, must be taught everything they need to know in order to properly structure requests to the server.

                                  Human clients are mostly assumed to have some base knowledge (such as knowing how to fill in their name and address), yet even still there is training on line even as we speak. A simple example is the credit card "security code". Most every decent shopping cart implementation has some kind of "what's this" explanation as to what the code is and where to get it.

                                  Machines are no different. Whereas as a designer one can basically assume some baseline of user knowledge, especially for wide spread domains like shopping, there's usually no assumption of that for machine clients. We can, however, rely on institutional knowledge by relying on things like standard formats. If you use HTML, you don't have to explain the semantics of processing HTML as part of your interface. You only have to explain how the HTML is used for your application (i.e. where to get the data bits and what goes in form fields for example). Just like for a human.

                                  Much like a human. In a specialized domain (say, health care), you can't simply plop an untrained user in front of a complicated application. By using HTML, they already get those semantics "for free" because they have an ubiquitous browser as an HTML processor. But you still need to train them as what the various requests do, and what the arguments are, and how those arguments are formatted and validated. There's a lot of domain knowledge that has to instilled in that user before they can use the application.

                                  A machine client is no different. There's no magic here at this level.

                                  Regards,

                                  Will Hartung
                                  (willh@...)
                                   
                                   
                                • Philippe Mougin
                                  ... Hi Jakob, It is quite RESTful to actually use HTML forms to dynamically instruct non human clients how to constructs URLs. So I don t think you were
                                  Message 16 of 16 , Aug 9, 2011
                                    Le 9 août 2011 à 08:56, Jakob Strauch a écrit :

                                    > Thank you all for your comments. I think my misleading assumption was, that a client can be dynamically tought by the server to construct a message by sending a HTML Form.
                                    >
                                    > While a real user would know from the web application context, where to place his name and adress, how could a machine do that?

                                    Hi Jakob,

                                    It is quite RESTful to actually use HTML forms to dynamically instruct non human clients how to constructs URLs. So I don't think you were mislead in the first place. The client has to know (e.g, from documentation) things like where to put the name, the address and so on, but it also gets dynamically from the form many information on how to construct the URL: the scheme, host and path can be communicated by the form's action attribute and the query string parameter names can be given by the form's "input" elements (for example, the documentation might state "The actual name of the query parameter for the address is given by the form's input element with an id attribute equals to 'address' ").
                                    HTML forms are not as powerful as some other hypermedia controls (e.g., form-derived URLs are always based on query strings) but are often used because they are easy to interpret client-side, and thus might constitute an acceptable compromise between support for hypermedia and actual usability.
                                    If/when we get good client libraries for URI templates, XForms or other wonders, this might change.

                                    The usefulness of a text/form+html media type is another question, though.

                                    Philippe
                                  Your message has been successfully submitted and would be delivered to recipients shortly.