> Hmmm. Looks like I'll have to learn more about this WADL.
Both WADL and WSDL2 can describe REST services. The latter is some time
away, and WADL, whilst young, is here right now:
https://wadl.dev.java.net/
> I was
> approaching it from the XSLT side. Should've thought about the web
> servic
Hmmm. Looks like I'll have to learn more about this WADL. I was
approaching it from the XSLT side. Should've thought about the web
service side.
Thanks!
(Being a one man shop and very busy, I often end up reinventing the
wheel. It's a drag. I should get out more.)
Chas.
Tim Perrett wrote:
>
Chas,
What your talking about is object serilization - the helpers we both
currently have, and the ones I plan to rebuild do not care about the
output XML - it's more abstract than that (collections of implicit
conversions etc)
IMO - what your talking about is object serilization. There ar
Tim,
I don't know much about the XMLApiHelper, but if you're headed down this
route, there is an alternative syntax that you might want to consider.
One of the things I might want to do with XML output from a REST server,
for example, is create an interface to it using HTML. The easiest way
w
Mmmm - I see value in HTTP responses being in one file, and as far as im
aware that's the case now? IMO, the file was massively cluttered before with
CSS responses, JS responses (of which there are a lot) etc etc etc. Having
them a little segregated makes the code easier to maintain.
What are you
On Sat, Jan 31, 2009 at 7:53 AM, Tim Perrett wrote:
>
>
> Hey David,
>
> Ok splendid - another alternative it is.
>
> FYI - I added a few more HTTP code representations to HttpResponse.scala
> last night... Nothing crazy, but just some other ones I needed. I also need
> to add some extra paramete
Hey David,
Ok splendid - another alternative it is.
FYI - I added a few more HTTP code representations to HttpResponse.scala
last night... Nothing crazy, but just some other ones I needed. I also need
to add some extra parameters to some of them so they directly represent the
RFC spec, but they
Tim,
Please don't change the existing XMLApiHelpers, but feel free to create an
alternative. I expect different people are going to have different styles
and providing them with lots of alternatives will be important.
I'm planning another alternative that will returns failures as different
HTTP c
