Will, you articulate matters so well. This is a great starter for this
discussion. Sad to say I am not up on my REST knowledge so I see now I
have some reading to do. You know, back in my day, all we had was GET
and POST....ha, just kidding. I'm not that old.
My only initial comment tonight is regarding the annotation @Http. If
this goes somewhere and it is decided to do it this way I think I would
prefer the main annotation to be @REST/@Rest. Reason being, to me, it
is more logical and makes more sense at a glance. So taking a couple of
your examples...
// Default rest binding
public class PersonActionBean {
@Rest
public Resolution post() { ... }
@Rest
public Resolution get() { ... }
@Rest
public Resolution delete() { ... }
@Rest {method="MYHTTPVERB"}
public Resolution myHttpVerb() { ... }
}
@Rest(method={HttpVerb.DELETE, HttpVerb.PUT}, customMethod=
{"MYDELETE", "MYPUT"}, eventName="shazam", default=true)
To me this, at a glance, this makes more sense and signifies we are
doing RESTful operations. What do you think? As far as everything else,
like I said, I have some reading to do. But great start man.
Gregg
Will Hartung wrote:
> We were babbling on IRC, as we tend to do. I mumbled about this a
> couple of days ago, and then Double-A Porter got on his bullhorn
> about StripesStuff.
>
> I want to explore adding a more formal REST capability to Stripes.
>
> I think that there is great value is adding better "full bodied" REST
> Support to an Action framework like Stripes.
>
> If you cruise around the Intratubes, you'll find that we have Action
> Frameworks, but we also have REST Specific frameworks as well.
>
> Turns out the Action frameworks don't actually support REST as well
> as they could, and REST frameworks don't support classic web apps
> very well, if at all.
>
> Now, some may say "WTH? What's so hard about REST? It's just HTTP, eh?"
>
> Yes, it is just HTTP. Which is why it's kind of silly to need two
> "HTTP" Frameworks to make writing this server side logic.
>
> "But if REST is just HTTP, why can't we just use Stripes out of the
> box?" Well, first it doesn't come in a box -- you have to download
> it. But, be that as it may, Stripes, like most every other Action
> Framework, actually supports only a subset of HTTP.
>
> For example, we had the post earlier about the other HTTP verbs and
> how, save for GET and POST, Stripes pretty much just shows them the
> door.
>
> That's Bad(tm).
>
> See, the REST wonks want to use all of those other verbs: HEAD, PUT,
> DELETE, etc. In fact, some want to make their own as well (for
> example, WebDAV creates its own HTTP verbs). This is fully within the
> HTTP spec, making this stuff up as you go.
>
> Now, while you Cro-Magnon web page grognards from the "when I was a
> kid, all we had was GET, 14K modems, and Perl" school of web
> programming are happy with the status-quo. REST aficionados, umm, ain't.
>
> Fortunately, it should not be a real leap to bring Stripes in to the
> 21st century, and be a Good Citizen with the rest of the HTTP protocol.
>
> Ideally, this can all be done in Stripes Stuff with interceptors, so
> as not to need to change Stripes core and offend Tim and his "GET OFF
> MY LAWN" ways.
>
> I think the primary thing is to be able to expose the HTTP verb as a
> first class part of the binding and event mechanism.
>
> The requirements are:
>
> + Stripes works as it always has -- this is an "opt in" system. So,
> breaking classic Stripes is off the table.
> + First class handling of the Standard HTTP verbs: GET, PUT, POST,
> DELETE, HEAD, OPTIONS. TRACE and CONNECT appears to be server level
> Verbs, so we'll punt on those.
> + Ability to support other verbs. This means, basically, being able
> to bind to a String.
> + Better support, perhaps through utility methods for content
> negotiation, HTTP headers, and response codes. Response codes are a
> Big Deal to REST folks, so they should be easy.
> + Easy return of ValidationErrors in some format besides HTML (i.e.
> XML or JSON)
> + Ideally, binding to other data types beside multipart form
> requests, notably XML and JSON, though this is at the bottom of the
> list for a reason.
>
> In REST, it's important that the same URL do different things
> depending on the verb.
>
> Right now, Stripes conflates GET and POST to mean the same thing. To
> the REST cognoscenti, the two are quite, quite, different. So, we
> need to be able to readily handle differentiating those two kinds of
> requests, even tho the URL is identical.
>
> There's two ways to do that.
>
> One is annotating a method with @Rest, or @Http or something, and
> then using a configuration by convention meme base on the name of the
> event.
>
> For example:
>
> // Default rest binding
> public class PersonActionBean {
> @Http
> public Resolution post() { ... }
> @Http
> public Resolution get() { ... }
> @Http
> public Resolution delete() { ... }
> @Http {method="MYHTTPVERB"}
> public Resolution myHttpVerb() { ... }
> }
>
> If an event is passed, we could do:
>
> public class PersonActionBean {
> // For event name "view"
> @Http
> public Resolution postView() { ... } // should this be viewPost?
> @Http
> public Resolution getView() { ... }
> @Http
> public Resolution deleteView() { ... }
> @HandlesEvent("view") // stock stripes annotation
> @Http {customMethod="MYHTTPVERB"}
> public Resolution myHttpVerbForViewEvent() { ... }
> }
>
> If we punt on CbC, and be explicit we can do:
>
> @Http(method={HttpVerb.DELETE, HttpVerb.PUT}, customMethod=
> {"MYDELETE", "MYPUT"}, eventName="shazam", default=true)
>
> where
>
> method = The HTTP verbs that this event would bind too.
> customMethod = Custom HTTP verbs to bind to
> eventName = the name of the event to bind too
>
> And stock @DefaultHandler would be used to tell us that it's the
> default for that specified methods.
>
> By default, any event that isn't annotated would be considered as
> method={HttpVerb.POST, HttpVerb.GET}, i.e. both, like Stripes is now.
>
> Does anyone like or dislike either of these techniques for binding
> events?
>
> For content negotiation, I think just some utility methods can be
> used to break up and make the content-types more available to the
> user. I don't see a need to dispatch on content type (though that
> could be interesting as well, I think it's something that could also
> be layered in later).
>
> For the Headers and ResultCodes, that can probably be handled with a
> couple of new Resolution types, I don't recall how stripes handles
> result codes right off the top of my head.
>
> We saw the issue that Freddy had with having to extend
> ForwardResolution to add his Success header, a customer resolution
> that lets us tack on headers would be trivial to do.
>
> As for returning errors in a different format than HTML, that could
> also be done, I think through a custom resolution,
> JSONErrorsResolution, or XMLErrorResolution, and the dispatch code
> could (somehow) know which one to you, either by configuration or,
> ideally, content negotiation.
>
> For now, I'll punt on potentially binding other data type for input
> besides mutlpart form requests. I think there's value here, as many
> REST services are POX services, as well as multipart, and Ajaxy types
> like chatting in JSON.
>
> The basic thought was that the process would "flatten" the in coming
> XML or JSON into, effectively, multipart parameters, and then let
> Stripes do the rest of the work. Also, we make available, perhaps,
> the DOM of the XML if the action has a Document field. And, perhaps,
> something appropriate for JSON (I don't know much about JSON, so I
> can't say what this would be, heaps of bags of maps of maps maybe).
>
> Obviously, if you send stuff that the standard Stripes binding can't
> do, then, well,it doesn't work. Don't do that. Be nice to Stripes,
> it'll be nice to you.
>
> Save for the potential binding of incoming data, you can see that
> this should not be a horrible amount of work.
>
> And I'm not suggesting anyone take it on, or that the Stripes guys do
> it.
>
> But I would like to have your thoughts about the approach, which you
> like better, and any suggestions that y'all might have.
>
> Regard,
>
> Will Hartung
>
>
> -------------------------------------------------------------------------
> 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
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
-------------------------------------------------------------------------
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
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
