TaskList Sample app and tutorial posted
mca
exyus here:
http://exyus.com/articles/tasklist/
feedback is welcome!
Mike Schinkel
> I posted a live sample app and a tutorial on how i built it using
> exyus here:http://exyus.com/articles/tasklist/
How does the UriPattern work? Let's say I wanted to have a web service that
listed cars:
For each make I'd like a URL that would return a list of models and years:
http://api.example.com/cars/{make}
i.e.
http://api.example.com/cars/toyota
http://api.example.com/cars/ford
http://api.example.com/cars/mercedes
How would I map that? Can I use a UriTemplate?
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org
mca
sorry for the slow response...
one key point to start with. all URLs get ".xcs" tacked onto the end
of the document. that means you example URLs really look like this:
http://api.example.com/cars/toyota.xcs
http://api.example.com/cars/ford.xcs
http://api.example.com/cars/mercedes.xcs
this is usually handled by the isapi_rewrite.
here's an example of the /cars/{make} regular expression w/ comments:
// /cars/(?<make>[^/?]*)?(?:\.xcs)(?:.*)?
//
// Options: case insensitive
//
// Match the characters "/cars/" literally <</cars/>>
// Match the regular expression below and capture its match into
backreference with name "make" <<(?<make>[^/?]*)?>>
// Between zero and one times, as many times as possible, giving
back as needed (greedy) <<?>>
// Match a single character NOT present in the list "/?" <<[^/?]*>>
// Between zero and unlimited times, as many times as possible,
giving back as needed (greedy) <<*>>
// Match the regular expression below <<(?:\.xcs)>>
// Match the character "." literally <<\.>>
// Match the characters "xcs" literally <<xcs>>
// Match the regular expression below <<(?:.*)?>>
// Between zero and one times, as many times as possible, giving
back as needed (greedy) <<?>>
// Match any single character that is not a line break character
<<.*>>
// Between zero and unlimited times, as many times as possible,
giving back as needed (greedy) <<*>>
some other points:
- this uses a feature of .NET that creates named arguments (the <make>
part)
- this rule treats everything after the .xcs as an optional single non-
captured variable (?:.*)?
this will set the XSL argument "$make" to "toyota", "ford", and
"mercedes" in your example URLs.
Hope this helps!
MCA
Mike Schinkel
> sorry for the slow response...
n/p
> one key point to start with. all URLs get ".xcs" tacked onto
> the end of the document. that means you example URLs really
> look like this:
> http://api.example.com/cars/toyota.xcs
> http://api.example.com/cars/ford.xcs
> http://api.example.com/cars/mercedes.xcs
God I really hate Microsoft's combined use of extensions in URLs for routing
and their antithapy towards empowering URL Design...
After having battled regular expressions for many years with ISAPI Rewrite
and later mod_rewrite I've come to believe that having RegEx requirement can
be one of the biggest impediments for the adoption of technology, even for
developers. RegEx are extremely fragile and only a small percent of
developers really understand them completely and intuitively. I think they
are a great idea but not a great implementation.
That said, URI Templates, though not w/o their complexity flaws, are much
more approachable, especially for simple use cases. Any chance you could
support them too, maybe with a UriTemplate as an alternate to a UriPattern?
Also, in your tutorial I notice that you didn't have
application/x-www-urlencoded as a content type for PUT and you didn't
include JSON at all. Why not and/or can I advocate you to consider doing
so?
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org
P.S. Have you seen the HeavyMetal REST Library? See:
http://forums.asp.net/t/941598.aspx
mike amundsen
first, IIS is the real culprit on using file extensions as routers for
URL dispatch. not sure if IIS7/ASP.NET 3.5 changes this, but it might.
once i get up to speed on the new release, things might change in this
area.
and yes, regexp is a tough slog. but to this point, i've found the
UriTemplate model a bit limiting. that said, i'm considering
supporting it somewhere along the way.
so far, i've concentrated on structured documents (XML valid) since
it's very easy to get up and running without a lot of code. I already
did a work up of this tasklist app using Atom, but need to clean it up
to post. i've not found a clean, two-way implementation of JSON for
.NET yet. ideally, i'd like to work with one that continues to
support structred docs (JSON-XML, XML-JSON). i'm still looking. let me
know what you like and i'll check it out.
MCA
--
mca
"In a time of universal deceit, telling the truth becomes a
revolutionary act. " (George Orwell)
Mike Schinkel
> first, IIS is the real culprit on using file extensions as
> routers for URL dispatch. not sure if IIS7/ASP.NET 3.5
> changes this, but it might.
> once i get up to speed on the new release, things might
> change in this area.
Actually, I started by typing "God I really hate IIS..." but realized that I
wasn't fully capturing the proper sentiment. It is Microsoft's antithapy
towards empowering URL Design that is why IIS is the way it was.
> and yes, regexp is a tough slog. but to this point, i've
> found the UriTemplate model a bit limiting. that said, i'm
> considering supporting it somewhere along the way.
How do you see it being limiting? Do you find it limiting in ways that
people actually use URLs, or does it limit in ways that for all practical
purposes don't matter with URLs? That said, I was proposing UriTemplate
support could be an alternate to URI Patterns so any limits in templates
could be handled by patterns. I bet if you implemented templates and people
start using Exyus you'll see a ratio of Pattern-to-Template use similar to
Amazon's ratio of SOAP-to-REST use (~ 15% to 85%).
And if you see it as really limiting in important ways, please make your
voice heard on u...@w3.org before it is too late and URI Templates are set in
stone.
> so far, i've concentrated on structured documents (XML valid)
> since it's very easy to get up and running without a lot of
> code.
Easy if you are using Visual Studio, but not if you are developing apps for
the LAMP stack. :-)
> I already did a work up of this tasklist app using
> Atom, but need to clean it up to post. i've not found a
> clean, two-way implementation of JSON for .NET yet.
I'm becoming of the opinion that it makes a lot of sense to have different
representations for upload and for download, and the simpler the better.
For a while I had the assumption I needed to PUT/POST the same
representation that I received from a GET and going with that assumption
really stunted my ability to do RESTful web services. It wasn't until after
I eliminated that (IMO artificial) constraint that REST got a lot easier for
me. After all, you are really just transmitting a respresentation of the
resource and a resource can have many different representations so why not
use one that is optimized for PUT/POST request and another that is optimized
for a GET response?
I like what Adam Bosworth says: "Simple things tend to work well, and
really simple things tend to work really well." So my advice: go with
simple, at least as an option.
> i'd like to work with one that continues to support structred
> docs (JSON-XML, XML-JSON). i'm still looking. let me know
> what you like and i'll check it out.
I'm not familiar with JSON-XML or XML-JSON...
mike amundsen
IIS/MS, take your pick - it's not pretty.
forgive my lack of clarity on uri-templates...
the MS implementation of UriTemplates in C# 3.0 is (IMHO) not too
good. the UriTemplate stuff you mention is top notch and i use it
quite often. check out the way i handle cache invalidation rules -
pure w3c uri-templates. in the case of my UriPattern attribute, so
far, reg ex makes it much easier for the code to *parse* the pattern
into valid dispatch. i'll continue to consider using the w3c
uri-template as a model for the UriPattern.
i've read your posts before on the issue of XML docs. too bad you're
not able to do easy work w/ XML in your environment. while my current
work with exyus focuses on XML valid docs, this is not essential to
the project. the base classes know nothing of XML and can easily do
anything you wish. i'll post an example using a base class this coming
weekend. that might give you some ideas.
as for representations...
i agree that there is nothing requiring representation parity for all
HTTP methods. Check out my use of UpdateMediaTypes. the tasklist
example uses text/html and text/xml as GET types, but
application/urlencoded-form and text/xml as PUT/POST types. you could
add any others you wish for either GET or PUT/POST (or both).
as for JSON-XML, i meant JSON-to-XML and XML-to-JSON. there are a
couple libraries that do this, but none i find very good.
it would be possible to build a low-level HTTPResource class in exyus
that handles JSON explicitly (JSONResource?), but i've not done that
work yet.
MCA
--
Mike Schinkel
> forgive my lack of clarity on uri-templates...
> the MS implementation of UriTemplates in C# 3.0 is (IMHO) not
> too good. the UriTemplate stuff you mention is top notch and
> i use it quite often. check out the way i handle cache
> invalidation rules - pure w3c uri-templates. in the case of
> my UriPattern attribute, so far, reg ex makes it much easier
> for the code to *parse* the pattern into valid dispatch. i'll
> continue to consider using the w3c uri-template as a model
> for the UriPattern.
Good points. Poor implementations are different than badly designed specs.
> i've read your posts before on the issue of XML docs. too bad
> you're not able to do easy work w/ XML in your environment.
It's not that I can't work with XML, it's just that JSON for response is
simpler (and I'm going with whatever is simplier these days), and so much
more usable in the browser context. With JSON, I don't want to have to work
with XML. Same is true for form encoding on requests.
> while my current work with exyus focuses on XML valid docs,
> this is not essential to the project. the base classes know
> nothing of XML and can easily do anything you wish. i'll post
> an example using a base class this coming weekend. that might
> give you some ideas.
Cool.
> as for representations...
> i agree that there is nothing requiring representation parity
> for all HTTP methods. Check out my use of UpdateMediaTypes.
> the tasklist example uses text/html and text/xml as GET
> types, but application/urlencoded-form and text/xml as
> PUT/POST types.
You must have added application/urlencoded-form to PUT; that's good.
BTW, wouldn't it be trivial to also support application/json as a GET type?
I mean you are not maintaining the data as XML internally, you are just
serializing it, right?
> as for JSON-XML, i meant JSON-to-XML and XML-to-JSON. there
> are a couple libraries that do this, but none i find very good.
Ah, yeah.
> it would be possible to build a low-level HTTPResource class
> in exyus that handles JSON explicitly (JSONResource?), but
> i've not done that work yet.
Ah, I guess that answers my question above. :-)
-Mike
P.S. My interest here is in encouraging useful RESTful architectures, not in
actually using Exyus. I'll send you a personal email about it.
mca
On Jan 29, 6:03 pm, "Mike Schinkel" <mikeschin...@gmail.com> wrote:
<snip>
> simpler (and I'm going with whatever is simplier these days), and so much
> more usable in the browser context. With JSON, I don't want to have to work
> with XML. Same is true for form encoding on requests.
I understand. esp. on the client-side, XML w/ javascript can a a
tussle. I still don't have a nice solution for the Safari browser.
And I understand the appeal of JSON. I've not done a lot with it yet
(no production apps), but it's on my list for 2008. I have no doubt
I'll find it useful<g>.
<snip>
> I mean you are not maintaining the data as XML internally, you are just
> serializing it, right?
For simple types, JSON support would not be too difficult. I actually
started mapping it out for this TaskList app last night. From what I
see, I should have it working by the end of the week (lots of other
stuff to do in the interim<g>).
And, yes, I *am* storing the data as an XML document. Makes it really
easy to transform into something else via XSLT. I've done RDF, Atom,
XHTML, CSV, already. JSON should not be too bad, eh?
MCA
Mike Schinkel
> I understand. esp. on the client-side, XML w/ javascript can
> a a tussle. I still don't have a nice solution for the Safari browser.
> And I understand the appeal of JSON. I've not done a lot with
> it yet (no production apps), but it's on my list for 2008. I
> have no doubt I'll find it useful<g>.
One word: jQuery
> <snip>
> > BTW, wouldn't it be trivial to also support
> application/json as a GET type?
> > I mean you are not maintaining the data as XML internally, you are
> > just serializing it, right?
> </snip>
>
> For simple types, JSON support would not be too difficult. I
> actually started mapping it out for this TaskList app last
> night. From what I see, I should have it working by the end
> of the week (lots of other stuff to do in the interim<g>).
Cool.
> And, yes, I *am* storing the data as an XML document.
Really. That's an interesting design decision.
> it really easy to transform into something else via XSLT.
> I've done RDF, Atom, XHTML, CSV, already. JSON should not be
> too bad, eh?
Have you seen all of these?
http://badgerfish.ning.com/
http://cse-mjmcl.cse.bris.ac.uk/blog/2006/02/12/1139757657653.html
http://zanstra.com/base/blog/xml2json
http://code.google.com/p/xml2json-xslt/
http://answers.google.com/answers/threadview?id=745221
http://www.jasonsalas.com/2006/05/convert-xml-to-json-through-xslt-for.html
http://dpn.name/index.php/2007/12/15/apml-json-xslt/
This is also kind of interesting, going the other direction:
http://goessner.net/articles/jsont/
mike amundsen
> One word: jQuery
</snip>
you know, i used this for a while - really like john resig and his
work - but dropped it a few months ago. for me, the whole "functional"
model is not easy for me. i like POJ (plain old javascript[g])
instead. I like dean edwards base2 and some of the work of christian
hielmann. i also have worked up my own ajax library that i've tweaked
over the last year. feels nice and comfy<g>.
<snip>
> > And, yes, I *am* storing the data as an XML document.
>
> Really. That's an interesting design decision.
</snip>
yeah, it's just *so easy* to store data in a structured form when you
don't want to/need take the time/effort to work up relational db. and
this task app is perfect example. two or three bits of data - why
build a data table, etc.? and w/ XML, i can use XSLT, XSD, EXSLT,
XPATH, XINCLUDE, ya-da ya-da. and that includes working up all the
other handy output representations (like PDF or JSON<g>) all using the
same tools.
in fact, my current database resource class for exyus is called
SqlXmlResource. it returns XML from the relational db! again, i can
easily transform the output of the db by just using an XSLT doc.
<snip>
> Have you seen all of these?
</snip>
i have most of these in my link list, but not all. thanks!
MCA
Mike Schinkel
> <snip>
> > One word: jQuery
> </snip>
>
> you know, i used this for a while - really like john resig
> and his work - but dropped it a few months ago. for me, the
> whole "functional"
> model is not easy for me. i like POJ (plain old
> javascript[g]) instead. I like dean edwards base2 and some of
> the work of christian hielmann. i also have worked up my own
> ajax library that i've tweaked over the last year. feels nice
> and comfy<g>.
Really?!? I guess to each his own.
>
> <snip>
> > > And, yes, I *am* storing the data as an XML document.
> >
> > Really. That's an interesting design decision.
> </snip>
>
> yeah, it's just *so easy* to store data in a structured form
> when you don't want to/need take the time/effort to work up
> relational db. and this task app is perfect example. two or
> three bits of data - why build a data table, etc.?
FYI, I ran my blog on dasBlog for years in part because I didn't have the
skills it would take to move to something else in a 1/2 day that I would
generally have to work on it. It used XML as a datastore instead of a
database. Frankly I've come to the point where I have developed a
==searing== ==hatred== of XML used as a datastore because of how dasBlog so
backed me into a corner and limited what I could do with it. Also I guess a
bit of that was searing hatred for ASP.NET too.
Ironically I am working literally tonight to move to WordPress (finally.) I
got tired of paying ServerIntellect over $100/mon for a VPS just to host my
blog and the next bill is due (this is no slight of them; they otherwise
provide great service but too expensive for me.)
> can do and w/
> XML, i can use XSLT, XSD, EXSLT, XPATH, XINCLUDE, ya-da
> ya-da. and that includes working up all the other handy
> output representations (like PDF or JSON<g>) all using the same tools.
For me, a SQL query tool is lightyears more functional than any of the X*
thingies. XML was a great idea at the time, but its evolved complexity made
it unworkable for what I call "occupational" programmers. If there were an
"standard" tool for interpretively querying XML data stores and doing
transforms, etc. like a SQL Query Analyzer I wouldn't be so anti-XML, but to
use XML you have to write programs. (Hey, maybe you could write one? Now
THAT would be a pretty damn nice concept, eh?)
BTW, I'm liking YAML more and more now that I realize it's not tied to the
Rails cult-of-personality.
> in fact, my current database resource class for exyus is
> called SqlXmlResource. it returns XML from the relational db!
> again, i can easily transform the output of the db by just
> using an XSLT doc.
Glad it works for you, but for me it's the epitome of tool-centric
development, which I've become a huge anti-fan of. (Ironic given that I
started VBxtras, eh? :)
But anyway, the world it filled with lots of different approaches. Don't
let my bias bother you too much on the server as many .NET people will be
fat and happy with what you are doing. But it would be nice if you could
make the interface the client sees more web-ish and less Microsoft-ish.
mike amundsen
> FYI, I ran my blog on dasBlog for years in part because I didn't have the
> skills it would take to move to something else in a 1/2 day that I would
> generally have to work on it. It used XML as a datastore instead of a
> database. Frankly I've come to the point where I have developed a
> ==searing== ==hatred== of XML used as a datastore because of how dasBlog so
> backed me into a corner and limited what I could do with it. Also I guess a
> bit of that was searing hatred for ASP.NET too.
never liked dasBlog. and my blog site is stored in a database, not in
XML. and i *query* it using SQL, not XML. but i *return* XML. for met,
XML is a representation, not a storage format. and i find that ASP.NET
is *lame* when it comes to supporting XML - despite lots of efforts to
the contrary.
> For me, a SQL query tool is lightyears more functional than any of the X*
> thingies. XML was a great idea at the time, but its evolved complexity made
> it unworkable for what I call "occupational" programmers. If there were an
> "standard" tool for interpretively querying XML data stores and doing
> transforms, etc. like a SQL Query Analyzer I wouldn't be so anti-XML, but to
> use XML you have to write programs. (Hey, maybe you could write one? Now
> THAT would be a pretty damn nice concept, eh?)
again, i don't *query* using XML. i'm not a masochist [g]! and i doubt
reasonable query tools for XML would be performant enough for the work
i currently do (500k+ user base and millions of page views/month). but
XSLT is a *great* way to generate representations. better an ASP or
ASP.NET for the work i do.
>
> BTW, I'm liking YAML more and more now that I realize it's not tied to the
> Rails cult-of-personality.
cults aside, i can see how YAML appeals, esp. to those who like JSON.
luckily, i can use transforms to ouput YAML when needed. happened only
once for me. customer introduced me to it. they had a "message" app
that pushed info around an internal network. back in 2003, i think.in
fact, we used a lot of regular expressions to route the data around,
too.
>
> Glad it works for you, but for me it's the epitome of tool-centric
> development, which I've become a huge anti-fan of. (Ironic given that I
> started VBxtras, eh? :)
surely you don't mean XML is a tool, right? Query Analyzer is a tool.
>... it would be nice if you could
> make the interface the client sees more web-ish and less Microsoft-ish.
that's actually one of the goals. when working with exyus, there are
very few MS-ism. no requirement for ASP/ASP.NET coding, no
requirement for MS SQL, no requirement for NTLM auth, etc.
as to the idea that .NET'ers would like what i'm attempting, there's
no indication of that yet. in fact, MS's new MVC over ASP.NET as well
as their WCF-REST work clouds the diferences on the surface. IMHO,
neither MVC, nor WCF (really SOAP) are the right way to handle HTTP.
that's why i'm doing exyus. for me, i get clean HTTP-compliant
functionality with very little compiled code. and i like that [g].
MCA
Mike Schinkel
> again, i don't *query* using XML. i'm not a masochist [g]!
> and i doubt reasonable query tools for XML would be
> performant enough for the work i currently do (500k+ user
> base and millions of page views/month). but XSLT is a *great*
> way to generate representations. better an ASP or ASP.NET for
> the work i do.
To each his own. :-) As you saw with my comments on rest-discuss, I
started thinking XSLT would be a great tool and now I'm at the point I
desipe it for the time it has wasted for me and the corners it backed me
into.
> luckily, i can use transforms to ouput YAML when needed.
> happened only once for me. customer introduced me to it. they
> had a "message" app that pushed info around an internal
> network. back in 2003, i think.in fact, we used a lot of
> regular expressions to route the data around, too.
When it comes down to it, ideally all the formats are just representations.
> > Glad it works for you, but for me it's the epitome of tool-centric
> > development, which I've become a huge anti-fan of. (Ironic
> given that
> > I started VBxtras, eh? :)
>
> surely you don't mean XML is a tool, right? Query Analyzer is a tool.
In that context I was thinking of XSLT, ESXLT, X-Query, etc as the tool, but
it was a bit of apple and oranges I admit. I was more remembering the guys
who said "It doesn't have to be hand-editable, we'll have tools for that."
Of course that only relates to XSLT in that XSLT is anything but simple. :)
> that's actually one of the goals. when working with exyus,
> there are very few MS-ism. no requirement for ASP/ASP.NET
> coding, no requirement for MS SQL, no requirement for NTLM auth, etc.
:-)
> as to the idea that .NET'ers would like what i'm attempting,
> there's no indication of that yet. in fact, MS's new MVC over
> ASP.NET as well as their WCF-REST work clouds the diferences
> on the surface. IMHO, neither MVC, nor WCF (really SOAP) are
> the right way to handle HTTP.
> that's why i'm doing exyus. for me, i get clean
> HTTP-compliant functionality with very little compiled code.
> and i like that [g].
I tend to agree. I started RESTian for similar reasons.
-Mike