NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
help them think they understand.
--Larry Wall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
ORLite has this problem (Score:1)
I've been finding I have something of this problem with ORLite, which is intended to give you a reasonable full ORM in one line of code.
The problem is that it isn't documented like regular code is documented. It just lets you call stuff based on the database structure, and I'm finding that very very annoying.
Apart from automatically generating POD for the documentation, I'm stuck at this point.
Re: (Score:2)
Alzabo did something similar, and I did write a complete POD generator.
However, it's a little different in this case, because it's generating an API based on a database you know about, so if the rules for API generation are predictable, knowing what the API will be is simple.
If you're writing a client for a REST service, you only know what the providers of the service tell you.
Something about roses and names (Score:1)
Just take the ideas you like about REST, build your API as you see fit and call it something else. POX/HTTP, or whatever.
Re: (Score:1)
As long as you understand what you lose by giving up constraints imposed by REST [plasmasturm.org], that’s perfectly fine.
Re: (Score:2)
AFAICT, I like everything about REST but the "start at the root and discover" rule. The rest of it, including what Roy said in his original blog post about using document types vs documenting "parameters, seems very sane.
But for me, non-interactive clients are the key target of a web-based API. I think browsers do an acceptable job of providing an interactive client already.
Re: (Score:1)
What I said stands: if you understand what you lose by giving up that rule (a lot – much more than naïvely obvious), go ahead and give it up.