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

Re: Another potential problem with the 311 proposal

Expand Messages
  • Jérôme Louvel
    Elliotte, Interoperability between clients and servers at the wire level is different from consistency between client-side and server-side API design,
    Message 1 of 23 , Feb 15, 2007
    View Source
    • 0 Attachment
      Elliotte,

      Interoperability between clients and servers at the wire level is
      different from consistency between client-side and server-side API
      design, especially when several implementations of the same API are
      expected. In our case (RESTful Web services API), the common
      denominator should be all of HTTP 1.1 and just HTTP 1.1.

      I don't think it would be wise to include any kind of object
      serialization to/from XML in such API if that is your concern. We
      don't want to fall into WS-* interop issues as you correctly point.

      > Consider a Representation class, for example. The server sends a
      > representation and the client receives it, so it should be appropriate
      > for them to use the same class to model it, right? Actually no. The
      > client and server have different views of this object. For instance the
      > server is probably going to want some sort of pointer back to the
      actual
      > resource from which the representation is derived while the client
      > should not see any such pointer.

      Talking about the Restlet's Representation class, it doesn't contain
      any reference to the parent Resource, so that is not an issue for us.
      We never had an user complaining about this design choice.

      > Furthermore, the client needs a way to get a byte array or
      InputStream for the message body in the Representation. The server
      needs a way to set the byte array or get an
      > OutputStream for the message body. If you try to get away with one
      > Representation class, then each side will have methods it doesn't need.

      In our case, we designed the Representation class like a Content (or
      like an HTTP entity if you prefer) that can be either written to an
      OutputStream (or to an NIO WritableByteChannel) or read by getting an
      InputStream (or an NIO ReadableByteChannel). We have several abstract
      implementations that can let you automatically convert from one IO
      mode to another. Have a look at this hierarchy diagram:
      http://www.restlet.org/tutorial#conclusion

      Check also the Javadocs of the org.restlet.resource package:
      http://www.restlet.org/docs/api/org/restlet/resource/package-summary.html

      Best regards,
      Jerome
    • Mark Baker
      ... I agree. Moreover, I also think you generally have different design goals with client and server APIs. For example performance is normally a lot more
      Message 2 of 23 , Feb 15, 2007
      View Source
      • 0 Attachment
        On 2/15/07, Elliotte Harold <elharo@...> wrote:
        > The only way to get the ideal client API is to design just a client API.
        > The only way to get the best serve side API is to design just a server
        > side API. If REST is done right, then we shouldn't need to coordinate
        > the two design efforts. The interfaces between the two should be limited
        > to HTTP.

        I agree. Moreover, I also think you generally have different design
        goals with client and server APIs. For example performance is
        normally a lot more important for servers than clients. Also, a
        simple API might be more desirable on the client than on the server
        (again, because of performance). For these reasons it will likely do
        more harm than good to try to use server abstractions in a client API
        or vice-versa.

        Mark.
        --
        Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
        Coactus; Web-inspired integration strategies http://www.coactus.com
      • Jérôme Louvel
        Hi Mark, ... I understand your point of view, but we also have to take into account applications that need high performance for clients too. Implementating
        Message 3 of 23 , Feb 15, 2007
        View Source
        • 0 Attachment
          Hi Mark,

          > I agree. Moreover, I also think you generally have different design
          > goals with client and server APIs. For example performance is
          > normally a lot more important for servers than clients. Also, a
          > simple API might be more desirable on the client than on the server
          > (again, because of performance). For these reasons it will likely do
          > more harm than good to try to use server abstractions in a client API
          > or vice-versa.

          I understand your point of view, but we also have to take into account
          applications that need high performance for clients too.
          Implementating transparent RESTful proxies for non-RESTful
          applications is a common use case where you need excellent
          performance, multi-threading on both sides of your application.

          FYI, we provide two client HTTP connectors (pluggable and using the
          same API), one based on JDK's HttpURLConnection and another based on
          Apache HTTP Client library.

          Also, in our case, you can directly set the client's output
          representation reference as the server's output representation,
          without reading/buffering anything. An optimized implementation of the
          Restlet API could even directly move bytes from client socket to
          server socket without consuming JVM memory thanks to Java's NIO.

          Anyway, we didn't find the sharing of common classes between the
          server-side and the client-side of the API to be an issue, it's even
          the opposite. For this design, we leveraged the notion of REST uniform
          interface (see our org.restlet.Uniform class) and the generic HTTP
          message aspects (entity headers common to both HTTP requests and
          responses). Just think about representations metadata (ETag, media
          type, encoding, etc.), their are strictly the same.

          Even the HTTP specification doesn't provide two separate definitions
          for requests and responses depending on whether you see the
          communication from the client end or from the server end of the
          connection, so why redefine them twice at the API level?

          Best regards,
          Jerome
        • Elliotte Harold
          ... Multiple implementations of the same API is rarely necessary and has resulted in overly complex designs throughout the Java class library. The big smell is
          Message 4 of 23 , Feb 15, 2007
          View Source
          • 0 Attachment
            Jérôme Louvel wrote:
            > Elliotte,
            >
            > Interoperability between clients and servers at the wire level is
            > different from consistency between client-side and server-side API
            > design, especially when several implementations of the same API are
            > expected. In our case (RESTful Web services API), the common
            > denominator should be all of HTTP 1.1 and just HTTP 1.1.

            Multiple implementations of the same API is rarely necessary and has
            resulted in overly complex designs throughout the Java class library.
            The big smell is use of the abstract factory design pattern. That's a
            sure sign of architecture astronautics and a confusing, hard-to-use,
            hard-to-deploy API.

            If multiple implementation are necessary, they should operate by
            replacing the JAR file with their own classes, not by using abstract
            factories to choose from among different classes at runtime. Abstract
            factories are only appropriate when the *same executing program* needs
            simultaneous access to more than one implementation. This rare and not
            the case here.

            Of course, adopting this principle would mean that the resulting work
            could not be bundled into the JDK. This would be a good thing. The JDK
            is already too big, and most people don't need this. This project makes
            a lot more sense a non-standard, open source development that can stand
            or fall on its own strengths and weaknesses, rather than one that is
            propped up by being bundled with the JDK.

            --
            Elliotte Rusty Harold elharo@...
            Java I/O 2nd Edition Just Published!
            http://www.cafeaulait.org/books/javaio2/
            http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
          • Mark Baker
            ... Then they can use an ... Seriously? I already gave an example of why they might need to be different; because the requirements and/or design goals may be
            Message 5 of 23 , Feb 15, 2007
            View Source
            • 0 Attachment
              On 2/15/07, Jérôme Louvel <contact@...> wrote:
              > Hi Mark,
              >
              > > I agree. Moreover, I also think you generally have different design
              > > goals with client and server APIs. For example performance is
              > > normally a lot more important for servers than clients. Also, a
              > > simple API might be more desirable on the client than on the server
              > > (again, because of performance). For these reasons it will likely do
              > > more harm than good to try to use server abstractions in a client API
              > > or vice-versa.
              >
              > I understand your point of view, but we also have to take into account
              > applications that need high performance for clients too.

              Then they can use an

              > Implementating transparent RESTful proxies for non-RESTful
              > applications is a common use case where you need excellent
              > performance, multi-threading on both sides of your application.
              >
              > FYI, we provide two client HTTP connectors (pluggable and using the
              > same API), one based on JDK's HttpURLConnection and another based on
              > Apache HTTP Client library.
              >
              > Also, in our case, you can directly set the client's output
              > representation reference as the server's output representation,
              > without reading/buffering anything. An optimized implementation of the
              > Restlet API could even directly move bytes from client socket to
              > server socket without consuming JVM memory thanks to Java's NIO.
              >
              > Anyway, we didn't find the sharing of common classes between the
              > server-side and the client-side of the API to be an issue, it's even
              > the opposite. For this design, we leveraged the notion of REST uniform
              > interface (see our org.restlet.Uniform class) and the generic HTTP
              > message aspects (entity headers common to both HTTP requests and
              > responses). Just think about representations metadata (ETag, media
              > type, encoding, etc.), their are strictly the same.
              >
              > Even the HTTP specification doesn't provide two separate definitions
              > for requests and responses depending on whether you see the
              > communication from the client end or from the server end of the
              > connection, so why redefine them twice at the API level?

              Seriously? I already gave an example of why they might need to be
              different; because the requirements and/or design goals may be
              different.

              That's not saying there won't be any shared API - I expect you could
              share a bunch of "util" classes. But I don't think it should be a
              goal to be able to share important chunks of the API between client
              and server. If that happens because the goals are similar enough,
              great, but it shouldn't itself be an objective IMO.

              Mark.
              --
              Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
              Coactus; Web-inspired integration strategies http://www.coactus.com
            • Mark Baker
              ... Oops. Meant to say They can use a high performance client API then . Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
              Message 6 of 23 , Feb 15, 2007
              View Source
              • 0 Attachment
                On 2/15/07, Mark Baker <distobj@...> wrote:
                > On 2/15/07, Jérôme Louvel <contact@...> wrote:
                > > Hi Mark,
                > >
                > > > I agree. Moreover, I also think you generally have different design
                > > > goals with client and server APIs. For example performance is
                > > > normally a lot more important for servers than clients. Also, a
                > > > simple API might be more desirable on the client than on the server
                > > > (again, because of performance). For these reasons it will likely do
                > > > more harm than good to try to use server abstractions in a client API
                > > > or vice-versa.
                > >
                > > I understand your point of view, but we also have to take into account
                > > applications that need high performance for clients too.
                >
                > Then they can use an

                Oops. Meant to say "They can use a high performance client API then".

                Mark.
                --
                Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                Coactus; Web-inspired integration strategies http://www.coactus.com
              • Elliotte Harold
                ... I haven t had as much time to spend getting familiar with RESTlet as I would like, but that s partially a function of its complexity, and that s partially
                Message 7 of 23 , Feb 15, 2007
                View Source
                • 0 Attachment
                  Jérôme Louvel wrote:

                  > In our case, we designed the Representation class like a Content (or
                  > like an HTTP entity if you prefer) that can be either written to an
                  > OutputStream (or to an NIO WritableByteChannel) or read by getting an
                  > InputStream (or an NIO ReadableByteChannel).

                  I haven't had as much time to spend getting familiar with RESTlet as I
                  would like, but that's partially a function of its complexity, and
                  that's partially a function of it working on both the client and the
                  server. Programs that act as both HTTP clients and servers are rare.
                  Usually I'm either writing a client or a server, not both.

                  If RESTlet were a pure server API, it would be simpler and I could learn
                  it and work with it faster. Ditto if it were a pure client API. I'm
                  unlikely to want both at the same time in the same program but because
                  you've tried to cover both use cases in the same product , it's become
                  quite a bit larger than it needs to be. The learning curve is not
                  linear. Complexity grows faster than the API footprint.

                  Now are there times when I want both? Yes, as you point out; but it
                  would be easier if I could learn them separately and treat them as
                  separate pieces. Or if I could easily use one but not the other. For
                  instance, I might want to use RESTlet for the server side but Apache
                  HTTPClient for the client.

                  --
                  Elliotte Rusty Harold elharo@...
                  Java I/O 2nd Edition Just Published!
                  http://www.cafeaulait.org/books/javaio2/
                  http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
                • Jon Hanna
                  ... I m very often writing programs that handle both sides of that equation at the same time. Usually my concerns about the app as a client and as a server are
                  Message 8 of 23 , Feb 15, 2007
                  View Source
                  • 0 Attachment
                    Elliotte Harold wrote:
                    > Programs that act as both HTTP clients and servers are rare.
                    > Usually I'm either writing a client or a server, not both.

                    I'm very often writing programs that handle both sides of that equation
                    at the same time. Usually my concerns about the app as a client and as a
                    server are very different, so even then I'm not seeing a lot of value in
                    there being all that much shared between the two.
                  • Elliotte Harold
                    ... The spec defines what it is. The API defines what you can do with it. The different ends of the connection want to do different things with the medium of
                    Message 9 of 23 , Feb 15, 2007
                    View Source
                    • 0 Attachment
                      Jérôme Louvel wrote:

                      > Even the HTTP specification doesn't provide two separate definitions
                      > for requests and responses depending on whether you see the
                      > communication from the client end or from the server end of the
                      > connection, so why redefine them twice at the API level?

                      The spec defines what it is. The API defines what you can do with it.
                      The different ends of the connection want to do different things with
                      the medium of transfer and consequently view it in different ways.

                      This is hardly unique to HTTP or software by the way. For instance,
                      McDonald's sees a hamburger very differently than I as a customer do.
                      For them it is an inventory item. For me it is lunch. Their operations
                      on the hamburger include reordering and cooking. Mine include eating.


                      --
                      Elliotte Rusty Harold elharo@...
                      Java I/O 2nd Edition Just Published!
                      http://www.cafeaulait.org/books/javaio2/
                      http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
                    • Elliotte Harold
                      ... There is not one API or library to rule them all, nor should their be, though standardization often attempts to create such a beast. Different use cases
                      Message 10 of 23 , Feb 15, 2007
                      View Source
                      • 0 Attachment
                        Jérôme Louvel wrote:

                        > I understand your point of view, but we also have to take into account
                        > applications that need high performance for clients too.
                        > Implementating transparent RESTful proxies for non-RESTful
                        > applications is a common use case where you need excellent
                        > performance, multi-threading on both sides of your application.
                        >

                        There is not one API or library to rule them all, nor should their be,
                        though standardization often attempts to create such a beast. Different
                        use cases require different libraries and APIs, even when they're doing
                        roughly the same thing, just at different scales.

                        The JDK needs a solid client side HTTP API, one that's better than
                        java.net.URL. This library should be optimized and designed for simple
                        use cases, and be adequate up to about the use a web browser or Atom
                        client would put it to.

                        If you're building a network proxy server or a multimillion feed
                        aggregator such as Bloglines, you need a different HTTP library to suit
                        your needs. I do not think this use case is common enough to justify
                        bundling such a thing with the JDK. Nor do I think we should try to make
                        one library serve both ends of the spectrum.

                        I suspect server side libraries should be limited to JEE and kept out of
                        JSE in general. Not everything needs to be bundled with the JDK in order
                        to be useful.

                        --
                        Elliotte Rusty Harold elharo@...
                        Java I/O 2nd Edition Just Published!
                        http://www.cafeaulait.org/books/javaio2/
                        http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
                      • Jérôme Louvel
                        Elliotte, ... In just two lines you can output the content of a Web page to the console. I don t think it is that complex compared to other APIs I ve seen:
                        Message 11 of 23 , Feb 15, 2007
                        View Source
                        • 0 Attachment
                          Elliotte,

                          > I haven't had as much time to spend getting familiar with RESTlet as
                          > I would like, but that's partially a function of its complexity, and
                          > that's partially a function of it working on both the client and the
                          > server.

                          In just two lines you can output the content of a Web page to the
                          console. I don't think it is that complex compared to other APIs I've
                          seen:

                          Client client = new Client(Protocol.HTTP);
                          client.get("http://www.restlet.org").getEntity().write(System.out);

                          Here is the simplest Restlet server you can build, no XML config
                          needed, no annotation, no container required, just a couple of JARs in
                          your classpath:

                          Restlet restlet = new Restlet() {
                          public void handle(Request request, Response response) {
                          response.setEntity("Hello World!", MediaType.TEXT_PLAIN);
                          }
                          };

                          // Create the HTTP server and listen on port 8182
                          new Server(Protocol.HTTP, 8182, restlet).start();

                          Of course, we support more complex cases like routing based on URI
                          templates, virtual hosting, transparent content negotiation.

                          > Programs that act as both HTTP clients and servers are rare.
                          > Usually I'm either writing a client or a server, not both.

                          I have seen other usages but that is not the most important point.
                          Just the fact that you can reuse your knowledge of the API when
                          writing a pure client then later a pure server seems useful no?

                          [...]

                          > Now are there times when I want both? Yes, as you point out; but it
                          > would be easier if I could learn them separately and treat them as
                          > separate pieces. Or if I could easily use one but not the other. For
                          > instance, I might want to use RESTlet for the server side but Apache
                          > HTTPClient for the client.

                          Nothing prevents you from doing that if you feel like it. The Restlet
                          framework never forces you to use the more complex artifacts if you
                          don't need them. But it seems nice to know they are here when needed.

                          Best regards,
                          Jerome

                          PS: The exact spelling is "Restlet" instead of "RESTlet" :-)
                        • Jérôme Louvel
                          Mark, ... Sorry, I missed your example. Could you point it to me? ... In our case, that was a goal added soon in the design process when we realized we were
                          Message 12 of 23 , Feb 15, 2007
                          View Source
                          • 0 Attachment
                            Mark,

                            > Seriously? I already gave an example of why they might need to be
                            > different; because the requirements and/or design goals may be
                            > different.

                            Sorry, I missed your example. Could you point it to me?

                            > That's not saying there won't be any shared API - I expect you could
                            > share a bunch of "util" classes. But I don't think it should be a
                            > goal to be able to share important chunks of the API between client
                            > and server. If that happens because the goals are similar enough,
                            > great, but it shouldn't itself be an objective IMO.

                            In our case, that was a goal added soon in the design process when we
                            realized we were duplicating too many artifacts. We even use the
                            same API to access to the file system (using file:// URIs), to the
                            classloader resources, to SMTP and JDBC servers. REST talks itself
                            about proxies to non-HTTP protocols.
                            http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_3_1

                            Of course, that isn't intended to replace dedicated SMTP, JDBC or File
                            APIs, but we've found it to be a useful level of abstraction.

                            Best regards,
                            Jerome
                          • Erik Hetzner
                            At Thu, 15 Feb 2007 11:25:05 -0500, ... This distinction between client & server APIs has hurt the REST style, in my opinion. An example: most *client* APIs
                            Message 13 of 23 , Feb 15, 2007
                            View Source
                            • 0 Attachment
                              At Thu, 15 Feb 2007 11:25:05 -0500,
                              Elliotte Harold wrote:
                              > The spec defines what it is. The API defines what you can do with it.
                              > The different ends of the connection want to do different things with
                              > the medium of transfer and consequently view it in different ways.

                              This distinction between client & server APIs has hurt the REST style,
                              in my opinion.

                              An example: most *client* APIs don’t deal well with large request
                              bodies. But they do deal well with large response bodies. With server
                              APIs it is of course the other way round; and most of them insist on
                              parsing your POSTed request body as x-www-url-encoded, even when it’s
                              not.

                              The REST style seems to encourage, as well, intermediary components:
                              caches, gateways, etc. A uniform client/server http API makes these
                              sort of components much easier to write.

                              I would rather have seen a low-level API to get at the http spec as
                              it is written, and then a simple API on top to get at the web as it is
                              lived.

                              best,
                              Erik Hetzner
                            • Jon Hanna
                              ... I don t see anything in the concept of either client API or server API that imlies Please suck at the following depending on whether you are a client
                              Message 14 of 23 , Feb 15, 2007
                              View Source
                              • 0 Attachment
                                Erik Hetzner wrote:
                                > An example: most *client* APIs don’t deal well with large request
                                > bodies. But they do deal well with large response bodies. With server
                                > APIs it is of course the other way round; and most of them insist on
                                > parsing your POSTed request body as x-www-url-encoded, even when it’s
                                > not.

                                I don't see anything in the concept of either "client API" or "server
                                API" that imlies "Please suck at the following depending on whether you
                                are a client or a server".
                              • Erik Hetzner
                                At Thu, 15 Feb 2007 19:05:44 +0000, ... I was a bit unclear. What I’m suggesting is that client & server APIs have different ways of getting at a message’s
                                Message 15 of 23 , Feb 15, 2007
                                View Source
                                • 0 Attachment
                                  At Thu, 15 Feb 2007 19:05:44 +0000,
                                  Jon Hanna <jon@...> wrote:
                                  >
                                  > Erik Hetzner wrote:
                                  > > An example: most *client* APIs don’t deal well with large request
                                  > > bodies. But they do deal well with large response bodies. With server
                                  > > APIs it is of course the other way round; and most of them insist on
                                  > > parsing your POSTed request body as x-www-url-encoded, even when it’s
                                  > > not.
                                  >
                                  > I don't see anything in the concept of either "client API" or "server
                                  > API" that imlies "Please suck at the following depending on whether you
                                  > are a client or a server".

                                  I was a bit unclear. What I’m suggesting is that client & server APIs
                                  have different ways of getting at a message’s body. So server APIs
                                  make it easy to return a large body of data in response to a request,
                                  and client APIs make it easy to process a large body of data returned
                                  as the body of a response, but neither make it easy to deal with a
                                  large body in a request message. Server APIs & implementations make it
                                  easy to get at the parameters of a POSTed x-www-url-encoded body, but
                                  they don’t make it easy to get at a request message body’s bytestream.

                                  Let’s say I’m coding a very simple proxy (if I make an obvious
                                  mistake, let me know here; I’ve never coded a proxy). If I get a POST
                                  request, I want to grab my request headers, figure out where I’m
                                  sending it, make a new request to the upstream server, then pipe the
                                  request body’s stream to an upstream request body’s stream and flush
                                  it. It has been my experience that this activity is complicated by
                                  a lack of uniformity between client & server APIs.

                                  best,
                                  Erik Hetzner
                                • Dave Orchard
                                  Jerome, There s a huge difference between a protocol specification such as HTTP and an API specification for a protocol. HTTP is the same for both client and
                                  Message 16 of 23 , Feb 15, 2007
                                  View Source
                                  • 0 Attachment
                                    Jerome,
                                     
                                    There's a huge difference between a protocol specification such as HTTP and an API specification for a protocol.  HTTP is the same for both client and sender because they both see the same things on the wire.  An API could be dramatically different based upon the needs of clients vs services, and what kind of infrastructure is available for use.  I'm not saying JSR 311 should have separate APIs for client/server, just pointing out that there are scenarios where it is desirable. 
                                     
                                    Cheers,
                                    Dave
                                     


                                    From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On Behalf Of Jérôme Louvel
                                    Sent: Thursday, February 15, 2007 7:48 AM
                                    To: rest-discuss@yahoogroups.com
                                    Subject: [rest-discuss] Re: Another potential problem with the 311 proposal

                                    Hi Mark,

                                    > I agree. Moreover, I also think you generally have different design
                                    > goals with client and server APIs. For example performance is
                                    > normally a lot more important for servers than clients. Also, a
                                    > simple API might be more desirable on the client than on the server
                                    > (again, because of performance) . For these reasons it will likely do
                                    > more harm than good to try to use server abstractions in a client API
                                    > or vice-versa.

                                    I understand your point of view, but we also have to take into account
                                    applications that need high performance for clients too.
                                    Implementating transparent RESTful proxies for non-RESTful
                                    applications is a common use case where you need excellent
                                    performance, multi-threading on both sides of your application.

                                    FYI, we provide two client HTTP connectors (pluggable and using the
                                    same API), one based on JDK's HttpURLConnection and another based on
                                    Apache HTTP Client library.

                                    Also, in our case, you can directly set the client's output
                                    representation reference as the server's output representation,
                                    without reading/buffering anything. An optimized implementation of the
                                    Restlet API could even directly move bytes from client socket to
                                    server socket without consuming JVM memory thanks to Java's NIO.

                                    Anyway, we didn't find the sharing of common classes between the
                                    server-side and the client-side of the API to be an issue, it's even
                                    the opposite. For this design, we leveraged the notion of REST uniform
                                    interface (see our org.restlet. Uniform class) and the generic HTTP
                                    message aspects (entity headers common to both HTTP requests and
                                    responses). Just think about representations metadata (ETag, media
                                    type, encoding, etc.), their are strictly the same.

                                    Even the HTTP specification doesn't provide two separate definitions
                                    for requests and responses depending on whether you see the
                                    communication from the client end or from the server end of the
                                    connection, so why redefine them twice at the API level?

                                    Best regards,
                                    Jerome

                                  • Jérôme Louvel
                                    Hi Dave, I think we agree. HTTP clients and servers do received the same Data but they use it in different ways. The Restlet API reuses the same classes to
                                    Message 17 of 23 , Feb 16, 2007
                                    View Source
                                    • 0 Attachment
                                      Hi Dave,

                                      I think we agree. HTTP clients and servers do received the same
                                      Data but they use it in different ways. The Restlet API reuses the
                                      same classes to model the Data exchanged but has separate classes to
                                      process it, depending on your role in the HTTP exchange (client or
                                      server). See Data definition in REST:
                                      http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_2_1

                                      My point is that there's no binary separation, life is a bit more
                                      complex here. Some artifacts can be shared between a client and server
                                      (the data and metadata), while others have to be designed specifically
                                      for clients or for servers. In the Restlet API, we've tried to find a
                                      balance between both needs: reuse and specificity.

                                      > I'm not saying JSR 311 should have separate APIs for client/server,
                                      > just pointing out that there are scenarios where it is desirable.

                                      In my opinion, JSR 311 should exclusively target the server-side role.
                                      The true challenge it to properly map between object-oriented domain
                                      objects (POJOs) and RESTful resources and representations. This is
                                      comparable to the mapping between POJOs and RDBMS (EJB/JPA/Hibernate)
                                      or between POJOs and RDF graphs (Sommer).

                                      Best regards,
                                      Jerome
                                    • Steve Loughran
                                      ... At the same time, on the assumption that servers often talk to remote systems, having the ability to chain stuff across the connection is kind of useful.
                                      Message 18 of 23 , Feb 16, 2007
                                      View Source
                                      • 0 Attachment
                                        On 2/16/07, Dave Orchard <orchard@...> wrote:
                                        >
                                        >
                                        > Jerome,
                                        >
                                        > There's a huge difference between a protocol specification such as HTTP and an API specification for a protocol. HTTP is the same for both client and sender because they both see the same things on the wire. An API could be dramatically different based upon the needs of clients vs services, and what kind of infrastructure is available for use. I'm not saying JSR 311 should have separate APIs for client/server, just pointing out that there are scenarios where it is desirable.
                                        >
                                        > Cheers,
                                        > Dave

                                        At the same time, on the assumption that servers often talk to remote
                                        systems, having the ability to chain stuff across the connection is
                                        kind of useful. In particular
                                        -a way to marshall failures without losing useful diagnostics can be handy
                                        -if the client is built around futures, state machines or some
                                        alternative to blocking RPC/RMI as a metaphor, then you'd like it
                                        somehow to integrate well with the server.

                                        -steve
                                      • Steve Loughran
                                        For those people who are not subscribed to the apache jcp-open mailing list, in which apache participation in/votes on JCP proposals are discussed, here is the
                                        Message 19 of 23 , Feb 17, 2007
                                        View Source
                                        • 0 Attachment
                                          For those people who are not subscribed to the apache jcp-open mailing
                                          list, in which apache participation in/votes on JCP proposals are
                                          discussed, here is the apache response. At Roy's request there's going
                                          be a name change to make it less "Java API For REST" to something less
                                          all-embracing, I dont know what, maybe
                                          "Java-API-to-keep-Java-Relevant-after-WS-*-failed"

                                          Given that sun's RI will be in glassfish, there's no financial value
                                          in keeping the TCK secret, so with any luck it will be open, and
                                          hosted on java.net .If it is fully open, then everyone can
                                          participate.

                                          Justin Erenkrantz is probably going to be apache lead, with various
                                          hangers on. Craig Russel (Tomcat) , Dims (Axis2), maybe me and dan
                                          diephouse. I am still trying to decide how much copious free time it
                                          merits.

                                          -steve

                                          -------- Original Message --------
                                          Subject: JSR-311 : that "REST" stuff that Roy keeps carrying on about...
                                          Date: Sat, 17 Feb 2007 06:56:46 -0500
                                          From: Geir Magnusson Jr.
                                          To: jcp-open

                                          :)

                                          Last night, Sun informed the EC regarding the changes made to title
                                          and package name.

                                          I voted yes this morning with the comment :

                                          "The ASF thanks the spec lead for making the changes to the title and
                                          package name as noted in a mail to the EC on 2/16/07 - this was a key
                                          requirement for us.

                                          We'd also like to encourage the spec lead to consider creating the
                                          software portion of the TCK as open source software, allowing
                                          community participation in designing as well as implementing the
                                          tests. There is successful precedent for this, and it wouldn't
                                          necessarily put compatibility of independent implementations nor the
                                          spec leads ability to command support or other revenue at risk if
                                          this path was chosen.

                                          Finally, we strongly urge the spec lead to "utilize" rather than
                                          "leverage" an open source development model for this JSR, to
                                          encourage as much participation from the community as possible - the
                                          community has a tremendous amount of experience using this
                                          architectural model, and it behooves the spec lead to take advantage
                                          of known best practices."
                                        • Benjamin Carlyle
                                          ... I am of the opinion that it can be useful to share the same abstraction, though it has to be fairly finely tuned and you may still have some tweaks on one
                                          Message 20 of 23 , Feb 18, 2007
                                          View Source
                                          • 0 Attachment
                                            On Thu, 2007-02-15 at 10:19 -0500, Mark Baker wrote:
                                            > On 2/15/07, Elliotte Harold <elharo@...> wrote:
                                            > > The only way to get the ideal client API is to design just a client
                                            > API.
                                            > > The only way to get the best serve side API is to design just a
                                            > server
                                            > > side API. If REST is done right, then we shouldn't need to
                                            > coordinate
                                            > > the two design efforts. The interfaces between the two should be
                                            > limited
                                            > > to HTTP.
                                            > I agree. Moreover, I also think you generally have different design
                                            > goals with client and server APIs. For example performance is
                                            > normally a lot more important for servers than clients. Also, a
                                            > simple API might be more desirable on the client than on the server
                                            > (again, because of performance). For these reasons it will likely do
                                            > more harm than good to try to use server abstractions in a client API
                                            > or vice-versa.

                                            I am of the opinion that it can be useful to share the same abstraction,
                                            though it has to be fairly finely tuned and you may still have some
                                            tweaks on one side or the other.

                                            I believe I am credited with helping inspire Jérôme's writing of the
                                            restlet framework, and I have developed a similar framework in-house for
                                            the company I work fork. It started out as mostly an interface class for
                                            interacting with a remote server, however we now also use it as part of
                                            the mechanism to accept client requests. I combine it with a simplified
                                            routes-like mechanism to locate an appropriate resource object which can
                                            then have calls made upon it. Most of our software acts both as client
                                            to something and server another. This is enterprise-scale REST rather
                                            than Web-scale.

                                            I admit it isn't perfect, but the opportunities to chain in extra
                                            authentication mechansims and other features have proven useful. It has
                                            also been easy to write little proxies to translate from one protcol to
                                            another, for example from HTTP to our internal protocols. In short, I
                                            think having a uniform interface in code has been a valuable way to
                                            bring the architectural constraints we are looking for closer to the
                                            developer.

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