RESTful controls

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RESTful controls

nmaves
I am just getting into this so excuse my ignorance.


I fully understand and use the new URLBinding in 1.5 and love it.

I am trying to find a way to redirect control based on the HTTP request type (PUT DELETE ...).  I want to be able to have an action mapping like /person which maps to the PersonActionBean which has all for the available actions.

What would be the best way to accomplish this in stripes?

Nathan

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: RESTful controls

Ben Gunter
I would probably do something like this in a base class and let subclasses override the Java methods that correspond to the HTTP methods they want to support.

    protected RuntimeException getException(String method) {
        return new UnsupportedOperationException("Method " + method + " is not supported by "
                + getClass());
    }

    @DefaultHandler
    public Resolution execute() {
        String method = getContext().getRequest().getMethod();
        if ("GET".equalsIgnoreCase(method)) {
            return GET();
        } else if ("POST".equalsIgnoreCase(method)) {
            return POST();
        } else if ("PUT".equalsIgnoreCase(method)) {
            return PUT();
        } else if ("DELETE".equalsIgnoreCase(method)) {
            return DELETE();
        } else {
            throw getException(method);
        }
    }

    protected Resolution GET() {
        throw getException(getContext().getRequest().getMethod());
    }

    protected Resolution POST() {
        throw getException(getContext().getRequest().getMethod());
    }

    protected Resolution PUT() {
        throw getException(getContext().getRequest().getMethod());
    }

    protected Resolution DELETE() {
        throw getException(getContext().getRequest().getMethod());
    }


On Thu, Jul 3, 2008 at 11:55 AM, Nathan Maves <[hidden email]> wrote:
I am just getting into this so excuse my ignorance.


I fully understand and use the new URLBinding in 1.5 and love it.

I am trying to find a way to redirect control based on the HTTP request type (PUT DELETE ...).  I want to be able to have an action mapping like /person which maps to the PersonActionBean which has all for the available actions.

What would be the best way to accomplish this in stripes?

Nathan


--
Ben Gunter
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: RESTful controls

Oscar Westra van Holthe - Kind
On 03-07-2008 at 13:58, Ben Gunter wrote:

> I would probably do something like this in a base class and let subclasses
> override the Java methods that correspond to the HTTP methods they want to
> support.
>
>     protected RuntimeException getException(String method) {
>         return new UnsupportedOperationException("Method " + method + " is
> not supported by "
>                 + getClass());
>     }
>
>     @DefaultHandler
>     public Resolution execute() {
>         String method = getContext().getRequest().getMethod();
>         if ("GET".equalsIgnoreCase(method)) {
>             return GET();
>         } else if ("POST".equalsIgnoreCase(method)) {
>             return POST();
>         } else if ("PUT".equalsIgnoreCase(method)) {
>             return PUT();
>         } else if ("DELETE".equalsIgnoreCase(method)) {
>             return DELETE();
>         } else {
>             throw getException(method);
>         }
>     }
[...]

For GET and POST this will work. However, Stripes does not call the
ActionBean for the other request methods. So PUT and DELETE will not work.
I assume this is because the HTML specification only allows the use of the
GET and POST HTTP request methods.

To change this, we'd need several changes:
- Binding and validation must now take into account that the request body
  doesn't contain input parameters (like for a POST request), but a binary
  blob that is to be put somewhere. Or alternatively, the InputStream of the
  request is left alone so the programmer can read the request himself (which
  the ActionBeanContext was supposed to abstract away from).
- The DispatcherServlet must re-implement the service() method, to detect the
  request methods HEAD, OPTIONS and TRACE, and direct them to the appropriate
  handler in HttpServlet. Other calls ultimately redirect to doPost(...),
  like GET and POST do mow.

All in all, I'm not certain if this can be done cleanly easily.


Oscar

--
   ,-_   So I believe [my version of the truth] until a voice on high
  /() )  says something different. And even then, I'll check to make
 (__ (   sure somebody didn't slip me some really interesting mushrooms
=/  ()   -- just in case.    -- Dark Paladin

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: RESTful controls

Ben Gunter-2
On Thu, Jul 3, 2008 at 2:54 PM, Oscar Westra van Holthe - Kind <[hidden email]> wrote:
On 03-07-2008 at 13:58, Ben Gunter wrote:
> I would probably do something like this in a base class and let subclasses
> override the Java methods that correspond to the HTTP methods they want to
> support.
>
>     protected RuntimeException getException(String method) {
>         return new UnsupportedOperationException("Method " + method + " is
> not supported by "
>                 + getClass());
>     }
>
>     @DefaultHandler
>     public Resolution execute() {
>         String method = getContext().getRequest().getMethod();
>         if ("GET".equalsIgnoreCase(method)) {
>             return GET();
>         } else if ("POST".equalsIgnoreCase(method)) {
>             return POST();
>         } else if ("PUT".equalsIgnoreCase(method)) {
>             return PUT();
>         } else if ("DELETE".equalsIgnoreCase(method)) {
>             return DELETE();
>         } else {
>             throw getException(method);
>         }
>     }
[...]

For GET and POST this will work. However, Stripes does not call the
ActionBean for the other request methods. So PUT and DELETE will not work.
I assume this is because the HTML specification only allows the use of the
GET and POST HTTP request methods.

To change this, we'd need several changes:
- Binding and validation must now take into account that the request body
 doesn't contain input parameters (like for a POST request), but a binary
 blob that is to be put somewhere. Or alternatively, the InputStream of the
 request is left alone so the programmer can read the request himself (which
 the ActionBeanContext was supposed to abstract away from).
- The DispatcherServlet must re-implement the service() method, to detect the
 request methods HEAD, OPTIONS and TRACE, and direct them to the appropriate
 handler in HttpServlet. Other calls ultimately redirect to doPost(...),
 like GET and POST do mow.

All in all, I'm not certain if this can be done cleanly easily.


Oscar

Both good points. I believe for a POST request, the input stream will only be read if the content type is either application/x-www-form-urlencoded (by the container) or multipart/form-data (by a multipart wrapper via Stripes). If you use a content type other than those two you should be OK. As for the second point, you could subclass DispatcherServlet and override service(..) to call doPost(..) in all cases.

-Ben
 

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users