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

Re: [rest-discuss] MVC style REST scenarios

Expand Messages
  • Bob Haugen
    You might also want to look at Django-piston: http://bitbucket.org/jespern/django-piston/wiki/Home
    Message 1 of 8 , May 3, 2009
    • groovepapa82
      A work-in-progress in this area is a collection of new Zend_Rest_* classes in the Zend Framework for PHP.
      Message 2 of 8 , May 3, 2009
        A work-in-progress in this area is a collection of new Zend_Rest_* classes in the Zend Framework for PHP.

        http://framework.zend.com/wiki/display/ZFPROP/Zend_Controller_Router_Route_Rest+-+Luke+Crouch

        We are using this kind of MVC design + RESTful architecture on our API and I'm enjoying it. Of course, I wrote it so I'm 100% biased. :) But hopefully it can give you some additional ideas.

        -L

        --- In rest-discuss@yahoogroups.com, Anand Ramanathan <rcanand@...> wrote:
        >
        > Thanks, Peter.
        >
        > That was very useful. Is your API built with this model public? It
        > would be useful to play with it to get a first hand experience.
        >
        > Thanks much
        > Anand
        >
        > On Fri, May 1, 2009 at 1:14 PM, Peter Keane <pkeane@...> wrote:
        > > On Fri, May 1, 2009 at 2:16 PM, rcanand <rcanand@...> wrote:
        > >>
        > >>
        > >> Hi,
        > >>
        > >> Can anyone share their experiences with designing REST APIs using MVC style
        > >> frameworks (such as Rails, Django,PHP MVC, etc.)?
        > >>
        > >> There seem to be two ways to design such APIs when accompanied with UI -
        > >> 1) APIs and UIs in separate spaces (having a separate URI path for API
        > >> versus UI for the same resource)
        > >> 2) Same URI for each resource, but using some form of content negotiation to
        > >> return UI formats like html or API formats like XML.
        > >>
        > >> Do you have any thoughts on the advantages and disadvantages of using either
        > >> approach?
        > >>
        > >
        > > Hi Anand-
        > >
        > > I went back and forth on this very thing, and ultimately decide to mix
        > > everything together. The URI path only supplies the "model" (actually
        > > controller, but those generally map to domain models), and the
        > > controller itself dispatches on method (GET,PUT,POST,DELETE), resource
        > > (we use URI regex-based routing w/ in each controller) and format.
        > > Formats are specified by extension (.json,.html,.atom).
        > >
        > > So the "widgets" controller has a routing map:
        > >
        > > $routes = array(
        > > � � '/' => 'widgets', � � � � � � � � � � �// http://myapp/widgets
        > > � � '/{widget_id}' => 'widget' � � � �// http://myapp/widget/23
        > > �);
        > >
        > > And defines functions by a convention: {method}{resource}{format} for example:
        > >
        > > function getWidgetJson($request) {
        > >
        > > }
        > >
        > > function putWidgetAtom($request) {
        > > � � � � � � $widget_id = $request->get('widget_id');
        > > � � � � � �etc....
        > > }
        > >
        > > function getWidgetsHtml($request) {
        > > � � � � �create HTML displayin list of widgets
        > > }
        > >
        > > function postToWidgets($request) {
        > > � � � � � $posted = $request->getBody();
        > > � � � � � $mime_type = $request->getMediaType();
        > > � � � � � dispatch here based on mime_type of posted resource (usually atom)
        > > � � � � � etc....
        > > }
        > >
        > > I have found this organizational structure to work well. �The main
        > > problem (which I did not show here) is the need to define
        > > authentication type either per handler or (as is usuallly the case)
        > > per method. �We use three auth types: �HTTP basic, a cookie-based
        > > Auth, and no auth. �Other than that, it works well.
        > >
        > > --peter keane
        > >
        > >
        > >
        > >> Thanks
        > >> Anand
        > >>
        > >>
        > >
        >
      • Sebastien Lambla
        And in the .net world you have OpenRasta http://trac.caffeine-it.com/openrasta ... From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
        Message 3 of 8 , May 4, 2009
          And in the .net world you have OpenRasta
          http://trac.caffeine-it.com/openrasta


          -----Original Message-----
          From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
          Behalf Of groovepapa82
          Sent: 03 May 2009 22:50
          To: rest-discuss@yahoogroups.com
          Subject: [rest-discuss] Re: MVC style REST scenarios

          A work-in-progress in this area is a collection of new Zend_Rest_* classes
          in the Zend Framework for PHP.

          http://framework.zend.com/wiki/display/ZFPROP/Zend_Controller_Router_Route_R
          est+-+Luke+Crouch

          We are using this kind of MVC design + RESTful architecture on our API and
          I'm enjoying it. Of course, I wrote it so I'm 100% biased. :) But hopefully
          it can give you some additional ideas.

          -L

          --- In rest-discuss@yahoogroups.com, Anand Ramanathan <rcanand@...> wrote:
          >
          > Thanks, Peter.
          >
          > That was very useful. Is your API built with this model public? It
          > would be useful to play with it to get a first hand experience.
          >
          > Thanks much
          > Anand
          >
          > On Fri, May 1, 2009 at 1:14 PM, Peter Keane <pkeane@...> wrote:
          > > On Fri, May 1, 2009 at 2:16 PM, rcanand <rcanand@...> wrote:
          > >>
          > >>
          > >> Hi,
          > >>
          > >> Can anyone share their experiences with designing REST APIs using MVC
          style
          > >> frameworks (such as Rails, Django,PHP MVC, etc.)?
          > >>
          > >> There seem to be two ways to design such APIs when accompanied with UI
          -
          > >> 1) APIs and UIs in separate spaces (having a separate URI path for API
          > >> versus UI for the same resource)
          > >> 2) Same URI for each resource, but using some form of content
          negotiation to
          > >> return UI formats like html or API formats like XML.
          > >>
          > >> Do you have any thoughts on the advantages and disadvantages of using
          either
          > >> approach?
          > >>
          > >
          > > Hi Anand-
          > >
          > > I went back and forth on this very thing, and ultimately decide to mix
          > > everything together. The URI path only supplies the "model" (actually
          > > controller, but those generally map to domain models), and the
          > > controller itself dispatches on method (GET,PUT,POST,DELETE), resource
          > > (we use URI regex-based routing w/ in each controller) and format.
          > > Formats are specified by extension (.json,.html,.atom).
          > >
          > > So the "widgets" controller has a routing map:
          > >
          > > $routes = array(
          > > � � '/' => 'widgets', � � � � � � � � � � �//
          http://myapp/widgets
          > > � � '/{widget_id}' => 'widget' � � � �//
          http://myapp/widget/23
          > > �);
          > >
          > > And defines functions by a convention: {method}{resource}{format} for
          example:
          > >
          > > function getWidgetJson($request) {
          > >
          > > }
          > >
          > > function putWidgetAtom($request) {
          > > � � � � � � $widget_id = $request->get('widget_id');
          > > � � � � � �etc....
          > > }
          > >
          > > function getWidgetsHtml($request) {
          > > � � � � �create HTML displayin list of widgets
          > > }
          > >
          > > function postToWidgets($request) {
          > > � � � � � $posted = $request->getBody();
          > > � � � � � $mime_type = $request->getMediaType();
          > > � � � � � dispatch here based on mime_type of posted resource
          (usually atom)
          > > � � � � � etc....
          > > }
          > >
          > > I have found this organizational structure to work well. �The main
          > > problem (which I did not show here) is the need to define
          > > authentication type either per handler or (as is usuallly the case)
          > > per method. �We use three auth types: �HTTP basic, a cookie-based
          > > Auth, and no auth. �Other than that, it works well.
          > >
          > > --peter keane
          > >
          > >
          > >
          > >> Thanks
          > >> Anand
          > >>
          > >>
          > >
          >




          ------------------------------------

          Yahoo! Groups Links
        • Eric J. Bowman
          ... ProductId: Aß/230/def If you don t want those slashes interpreted as part of a URI hierarchy: ProductId: Aß%2F230%2Fdef Escape them with
          Message 4 of 8 , May 8, 2009
            groovepapa82 wrote:

            >
            > http://framework.zend.com/wiki/display/ZFPROP/Zend_Controller_Router_Route_Rest+-+Luke+Crouch
            >

            "ProductId: 'Aß/230/def'"

            If you don't want those slashes interpreted as part of a URI hierarchy:

            ProductId: 'Aß%2F230%2Fdef'

            Escape them with percent-encoding in the URIs the apps generate. The
            link text, or @title, can provide human-readable slashes. This seems
            to be the sort of thing a framework should provide, IMHO.

            Nice work there, Luke.

            -Eric
          • Luke Crouch
            Cool. Thanks for the tip. -L ... Cool. Thanks for the tip. -L On Fri, May 8, 2009 at 4:07 AM, Eric J. Bowman wrote: ... ProductId:
            Message 5 of 8 , May 8, 2009
              Cool. Thanks for the tip.

              -L

              On Fri, May 8, 2009 at 4:07 AM, Eric J. Bowman <eric@...> wrote:
              "ProductId: 'Aß/230/def'"

              If you don't want those slashes interpreted as part of a URI hierarchy:

              ProductId: 'Aß%2F230%2Fdef'

              Escape them with percent-encoding in the URIs the apps generate.  The
              link text, or @title, can provide human-readable slashes.  This seems
              to be the sort of thing a framework should provide, IMHO.

              Nice work there, Luke.

              -Eric

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