On Tue, Jun 7, 2011 at 20:54, Michael Van Canneyt <mich...@freepascal.org>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. > > Michael. > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
