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

Re: [rest-discuss] ATOM Pub vs. JSON vs. ...?

Expand Messages
  • indresh malik
    Hi Philippe, May be i didnt understand your mail in totality, can you please elaborate what are the issues with APP? We are planning to start a new project
    Message 1 of 15 , May 29, 2012
    • 0 Attachment
      Hi Philippe,
      May be i didnt understand your mail in totality, can you please elaborate what are the issues with APP?

      We are planning to start a new project exposing REST interface and use APP/ATOM feeds for notifications.

      Appreciate your help!

      Thanks in advance,
      Indresh


      From: Philippe Rathé <prathe@...>
      To: Kristian Rink <kawazu428@...>
      Cc: Rest List <rest-discuss@yahoogroups.com>
      Sent: Tuesday, 29 May 2012 11:39 PM
      Subject: Re: [rest-discuss] ATOM Pub vs. JSON vs. ...?

       
      Hi Kristian,

      how could be atompub dead? People are just starting to understand
      REST, how could someone choose atompub when he doesn't understand
      REST?

      I'm starting to work on a side project that make uses of APP. I also
      noticed that it wasn't trendy. But when I realize
      the reasons were that nobody cares about interoperability and
      hypermedia driven application state,
      then my fear disappeared because I care. XML may be less trendy than
      JSON, that was I used to think. But I found my trend: XQuery in the
      backend and a native XML database, storing my feeds as-is.

      I felt that working with APP could be a good knowledge investment.
      That was a decision that came from my heart first. I recognized
      something strong in it.

      Good luck!

      On Tue, May 29, 2012 at 9:23 AM, Kristian Rink <kawazu428@...> wrote:
      > Folks;
      >
      > I am at the moment into trying to choose a data format / representation
      > to use for building a RESTful web service which should allow for reading
      > and writing resources, which should be accessible using "standard" tools
      > as well as using a dedicated programming API and which should as much as
      > somewhat possible rely upon existing open standards.
      >
      > After doing some reading, I came across Atom and APP as it seems in many
      > possible ways provide sane and stable solutions for problems at hand
      > (including things like "workspaces", "feeds", "entries", dealing with
      > service and category descriptions, dealing with textual and binary
      > content, dealing with extensibility and stuff like OpenSearch and the
      > like).
      >
      > In many ways, so far it seems the perfect match, however it right now
      > (at least for me) suffers from a particular shortcoming: I am not really
      > sure whether it's a technology or a standard to "last". Doing some
      > reading on that, I rather quickly stumbled across articles pointing out
      > that "AtomPub has failed" and "AtomPub is basically dead", suggesting
      > that everyone else uses JSON based REST services right now, eventually
      > pointing out that even the Google GData services are considered "legacy"
      > and replaced by different approaches right now. On the other hand I
      > don't really see what could replace Atom or especially AtomPub talking
      > about providing a given data structure, a data and service semantics to
      > allow for read/write interactions with a service in a somewhat sane,
      > standard way.
      >
      > So to ask: If you were about to start a new RESTful project supposed to
      > work with existing "standard" tools, what kind of data representation
      > would you choose? Would you still go for Atom / AtomPub? Would you
      > rather use some kind of JSON+HTTP? Something completely else?
      >
      > Thanks in advance for any input,
      > Kristian
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >


    • Philippe Rathé
      Hi Indresh, sorry if I wasn t clear. My intention was not to find issues to APP. I wanted to tackle the fact that APP was not trendy because the reason that
      Message 2 of 15 , May 30, 2012
      • 0 Attachment
        Hi Indresh,

        sorry if I wasn't clear. My intention was not to find issues to APP. I wanted to tackle the fact that APP was not trendy because the reason that makes APP awesome is the part in REST that is misunderstood. APP uses XML which sounds old for some. At least it is true in my entourage, which is mainly composed of young web developers. That is a constatation, but personally I would advocates APP, but I haven't work enough with it yet.

        If in your case you want to publish notifications, maybe you should consider only using Atom instead of AtomPub?

        In my case, I wasn't sure if APP was the right choice. But trying to express it within the constraints of APP just opened new horizon. I preferred to keep going with APP because of the  properties it induces in my architecture. Instead of bending the protocol to what I thought was my needs, I decided to harmonize with it by slightly revising my "needs".

        On Wed, May 30, 2012 at 2:03 AM, indresh malik <malik_indresh@...> wrote:
        Hi Philippe,
        May be i didnt understand your mail in totality, can you please elaborate what are the issues with APP?

        We are planning to start a new project exposing REST interface and use APP/ATOM feeds for notifications.

        Appreciate your help!

        Thanks in advance,
        Indresh


        From: Philippe Rathé <prathe@...>
        To: Kristian Rink <kawazu428@...>
        Cc: Rest List <rest-discuss@yahoogroups.com>
        Sent: Tuesday, 29 May 2012 11:39 PM
        Subject: Re: [rest-discuss] ATOM Pub vs. JSON vs. ...?

         
        Hi Kristian,

        how could be atompub dead? People are just starting to understand
        REST, how could someone choose atompub when he doesn't understand
        REST?

        I'm starting to work on a side project that make uses of APP. I also
        noticed that it wasn't trendy. But when I realize
        the reasons were that nobody cares about interoperability and
        hypermedia driven application state,
        then my fear disappeared because I care. XML may be less trendy than
        JSON, that was I used to think. But I found my trend: XQuery in the
        backend and a native XML database, storing my feeds as-is.

        I felt that working with APP could be a good knowledge investment.
        That was a decision that came from my heart first. I recognized
        something strong in it.

        Good luck!

        On Tue, May 29, 2012 at 9:23 AM, Kristian Rink <kawazu428@...> wrote:
        > Folks;
        >
        > I am at the moment into trying to choose a data format / representation
        > to use for building a RESTful web service which should allow for reading
        > and writing resources, which should be accessible using "standard" tools
        > as well as using a dedicated programming API and which should as much as
        > somewhat possible rely upon existing open standards.
        >
        > After doing some reading, I came across Atom and APP as it seems in many
        > possible ways provide sane and stable solutions for problems at hand
        > (including things like "workspaces", "feeds", "entries", dealing with
        > service and category descriptions, dealing with textual and binary
        > content, dealing with extensibility and stuff like OpenSearch and the
        > like).
        >
        > In many ways, so far it seems the perfect match, however it right now
        > (at least for me) suffers from a particular shortcoming: I am not really
        > sure whether it's a technology or a standard to "last". Doing some
        > reading on that, I rather quickly stumbled across articles pointing out
        > that "AtomPub has failed" and "AtomPub is basically dead", suggesting
        > that everyone else uses JSON based REST services right now, eventually
        > pointing out that even the Google GData services are considered "legacy"
        > and replaced by different approaches right now. On the other hand I
        > don't really see what could replace Atom or especially AtomPub talking
        > about providing a given data structure, a data and service semantics to
        > allow for read/write interactions with a service in a somewhat sane,
        > standard way.
        >
        > So to ask: If you were about to start a new RESTful project supposed to
        > work with existing "standard" tools, what kind of data representation
        > would you choose? Would you still go for Atom / AtomPub? Would you
        > rather use some kind of JSON+HTTP? Something completely else?
        >
        > Thanks in advance for any input,
        > Kristian
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >



      • Eric J. Bowman
        ... Spoken like someone who understood Roy s thesis. What s perfect may not be what s best. And, what already has high cache retention provides immediate
        Message 3 of 15 , May 30, 2012
        • 0 Attachment
          Kristian Rink wrote:
          >
          > Well actually, despite knowing there actually always will be some
          > differences in "mapping" a custom data semantics to an existing one,
          > I figured out that, in our given use case, the concepts of Atom and
          > APP both fit better than any other approach I found so far, and, then
          > again, seem to be backed by sufficient support (frameworks,
          > documentation, tools out there) to eventually provide a reliable
          > foundation being a "primary representation" in a prototype system
          > that doesn't want to come up with a custom / proprietary API which
          > essentially wouldn't do much more than re-inventing things like
          > workspaces, feeds, entries, categories (one of the things about Atom
          > that definitely got me enthusiastic about it when I started dealing
          > with it) or representations accepted when POSTing things to a certain
          > resource.
          >

          Spoken like someone who understood Roy's thesis. What's perfect may
          not be what's best. And, what already has high cache retention provides
          immediate benefit that's unlikely to diminish, which newer options
          won't be able to equal until some nebulous point in the future. The
          bandwagon may have passed Atom by, but I've never heard of it being de-
          allowed on intermediaries already configured for it; thus it is neither
          obsolete, nor without its advantages.

          -Eric
        • Eric J. Bowman
          ... Heheh... don t get me started. ;-) I still think this is the most important, and least-understood, concept in all of REST: The trade-off, though, is
          Message 4 of 15 , May 30, 2012
          • 0 Attachment
            Kristian Rink wrote:
            >
            > Am 29.05.2012 20:09, schrieb Philippe Rathé:
            > > how could be atompub dead? People are just starting to understand
            > > REST, how could someone choose atompub when he doesn't understand
            > > REST?
            >
            > Well yes; yet I see people who deal with REST hardly dealing with
            > Atom / APP. Most of the times indeed it ends up being some
            > proprietary XML or, more likely, some JSON media type being
            > considered "better suited", less overhead to deal with, easier to
            > deliver custom data structures. What they don't usually say (or see,
            > for that matter) is that, ultimately, again it ends up with systems
            > which seem somewhat tightly coupled, JavaScript code in the browser
            > or (even worse) external applications depending upon a custom data
            > structure which might or might not be required to undergo more or
            > less fundamental changes all along the way.
            >

            Heheh... don't get me started. ;-) I still think this is the most
            important, and least-understood, concept in all of REST:

            "The trade-off, though, is that a uniform interface degrades
            efficiency, since information is transferred in a standardized form
            rather than one which is specific to an application's needs. The REST
            interface is designed to be efficient for large-grain hypermedia data
            transfer, optimizing for the common case of the Web, but resulting in
            an interface that is not optimal for other forms of architectural
            interaction."

            If you can model your system as one of hypertext documents, then you
            don't need to make design tradeoffs in the name of less overhead, which
            tend to negate the benefits of REST. So, I say go for it with Atom.

            Maybe I'm just grumpy because yet another website I frequent now
            features a broken back button, paging back through script after script
            until finally, on the 4th or 5th click, user intent is finally
            respected. Or, because I can no longer right-click Google results to
            copy an URL, or any number of proliferating faults which break the Web
            by going against the "natural" architecture which are making it *less*
            usable and accessible, thanks to gratuitous use of JS.

            -Eric
          • Eric J. Bowman
            ... Also sounds like someone who understood Roy s thesis. Although I d say it s more about designing your system as hypertext documents, rather than Atom/APP
            Message 5 of 15 , May 30, 2012
            • 0 Attachment
              Philippe Rathé wrote:
              >
              > In my case, I wasn't sure if APP was the right choice. But trying to
              > express it within the constraints of APP just opened new horizon. I
              > preferred to keep going with APP because of the properties it
              > induces in my architecture. Instead of bending the protocol to what I
              > thought was my needs, I decided to harmonize with it by slightly
              > revising my "needs".
              >

              Also sounds like someone who understood Roy's thesis. Although I'd say
              it's more about designing your system as hypertext documents, rather
              than Atom/APP specifically; working within the idiom of REST should
              result in a system where media type is a bike-shed color which can be
              content-negotiated.

              -Eric
            • Kristian Rink
              Hi Eric, *; and thanks a bunch for your feedback. Well yes I read most of Roy s thesis and I certainly hope I understood some of the principles and ideas
              Message 6 of 15 , May 30, 2012
              • 0 Attachment
                Hi Eric, *;

                and thanks a bunch for your feedback. Well yes I read most of Roy's
                thesis and I certainly hope I understood some of the principles and
                ideas outlined there. ;)

                Anyway:

                Am 30.05.2012 18:10, schrieb Eric J. Bowman:
                > "The trade-off, though, is that a uniform interface degrades
                > efficiency, since information is transferred in a standardized form
                > rather than one which is specific to an application's needs. The REST
                > interface is designed to be efficient for large-grain hypermedia data
                > transfer, optimizing for the common case of the Web, but resulting in
                > an interface that is not optimal for other forms of architectural
                > interaction."

                Well, off-heart I guess we're not "traditional" hypermedia, we couldn't
                be less than that. We live off providing hosted, managed document
                management services for construction sites. However, I found that in
                many respects hypermedia concepts apply to the way we keep track of our
                document structures, as well. There are different customer projects.
                Workspaces. There are different groups of documents (drawings, photo
                documentation, lists, ...) inside each project (feeds), each of them
                allow for read/write access, though the latter usually limited to
                certain media types (PDF/HPGL/DWF for drawing layouts, JPG for images,
                PDF for virtually everything else). We have to keep track of what we see
                the "content" of a document (structured key/value metadata) and 1..n
                alternate representations (like a drawing which we have to keep three
                equivalent files of - HPGL, PDF, DWF). We have human-readable summaries
                (usually used by humans in order to tell what kind of document it is),
                creation / change dates, we have authors and different versions and the
                whole load. We have documents mainly sorted by key/value attributes,
                values being based upon predefined catalogs. Atom categories. That's
                what we eventually got. We need, in most cases, data exchange with
                systems which are "external" from our point of view. Document management
                installations at our customers sites. Competing application service
                providers. In all cases, it eventually boils down to transfering
                document content (metadata + files) periodically, polling and fetching
                what is new.

                I spent less than a few hours late one evening diving through some
                articles on Atom and repeatedly saw our use cases covered rather well by
                what Atom and APP provides. No, we're not a weblog provider or a news
                aggregator, but in some ways Atom and APP seems to make sense
                technically. Sure, it partially _is_ mapping our stuff to Atom/APP, but
                in the end we, well, end up with an external interface relying upon
                well-known technologies adhering to well-known semantics rather than
                re-inventing the same wheel in a slightly different way in SOAP like so
                many does. I then and now enjoy using SOAP, same as I did using CORBA
                before, but for this kind of purpose (exchanging information between
                different sites where anything else than the systems being loosely
                coupled is totally illusionary), things just get overly painful while
                manually crafting a custom media type. Did this using JSON in an early
                prototype, and learnt enough off this to want it really done with
                standards used more widespread when going productive. So far, it seems
                Atom/APP as primary media type, backed by HAL+JSON or the like as an
                alternative, seems a sane way here.


                > Maybe I'm just grumpy because yet another website I frequent now
                > features a broken back button, paging back through script after script
                > until finally, on the 4th or 5th click, user intent is finally
                > respected.

                Know what you mean. Then and now was hoping this behaviour would
                eventually be gone one day, but it seems it's still here to stay. :/

                Cheers,
                Kristian
              Your message has been successfully submitted and would be delivered to recipients shortly.