On Tue, 7 Jun 2011, ik wrote:
On Tue, Jun 7, 2011 at 20:54, Michael Van Canneyt <[email protected]>
wrote:
On Tue, 7 Jun 2011, ik wrote:
As you know REST is an architecture, not just a set of classes
or methods.
REST doesn't even require HTTP. So calling a webserver class
RESTsomething
because onGet, onPut, etc. are exposed does not have any added
value.
>I agree. This was why I didn't understand the original poster's
question; the
>implementation is trivial.
At the moment we are talking about HTTP, so TFPREST... for HTTP CGI
is actually in order.
The issue is not about writing 10 lines of code each time you need
to separate GET from PUT, but the fact that you repeat yourself
10 lines of code on each
location you require to this separation.
I'm using such work for example in Sinatra. I have an API for
having recordings after few of my applications (Asterisk based)
finished working. so you do
the following:
GET /recording/filename HTTP/1.1
.......
DELETE /recording/filename HTTP/1.1
.......
So you can download the recording (if exists) and delete it when no
longer need it.
If I require to implement the same thing on fpWeb, it actually
takes more code because there is no separation of any kind.
At the moment I wish to create a CRUD engine in fpWeb (and keep it
open source) that had a layer above databases, so you do not
provide direct access to the
database, but you provide access to the data, like a Proxy, but in
HTTP, so instead of using SQL (for example) you use JSON, and
instead of using Pg, Fb,
MySQL, SQLite etc... it is agnostic, and you control what user can
do what type of access and action etc...
This is all understood.
But Ludo is right in that a REST implementation is more than just routing the
HTTP method :-)
Yes, but here we are talking about CGI "engine" with a class that help you to
create a better support for REST, and that Class have a name that indicate
that it help to do exactly that.
Of course. TBaseRESTModule or so, to indicate that it's just basic :-)
Michael.
_______________________________________________
fpc-pascal maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
