Hello,

One of the thing that I find really missing in fpWeb is the ability to have support for REST.

That is, to place different callbacks to GET, POST, UPDATE, DELETE, HEAD and PUT.

Let's say that I create a support for the following PATH_INFO:

/records/

The class should have support imho to OnGet OnPost OnDelete etc.. So there will be separation of the code, while the OnRequest will fire anyway (if assigned) prior to each such request.
That way, it will be easier to separate code, but remain DRY.

Does anyone else find such feature something that can be useful for them ?

Ido

LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il

Why do you think this is missing ? fpWeb does not really care about the method.

What is DRY (other than opposed to WET ?)

Does anyone else find such feature something that can be useful for them ?

All you need to do is

   If Compare(ARequest.Method,'UPDATE') then
     DoYourUpdate(ARequest);

If you really want different events for the HTTP methods, you can make a descendent of TCustomHTTPModule which overrides HandleRequest() and which then examines the HTTP method and calls the appropriate callback for the various HTTP methods.

It can't possibly take you more than 15 minutes to code this, plus an additional 10 to register your new module in Lazarus.

And if you care to donate it, I'll put it in FPC.

Michael.

That's why it is missing :)

DRY = Don't repeat yourself. so if you have to do the same task for all of the requests, you can do them there ...

I'll see how to do it on Lazarus, never done it before, and it's time to learn.

And if you care to donate it, I'll put it in FPC.

I'm now testing my implementation that I called it TFPRESTWebModule. When it will be ready I'll open a "bug" with feature and a patch, and send here the open bug.

Michael.

Ido

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Please don't call it RESTsomething. REST involves much more than exposing http methods. Just to avoid that in the future somebody complains about missing REST features. Remember, a little while ago whe had somebody complaining about URIParser not supporting sip uri's ;)

What name do you think I should call it then ?

I don't care, as long it doesn't suggest features that aren't there. fpWeb2? fpikWeb? fpEasyWeb? fpWeb+? fpWebExposingHTTPMethods?

Ludo Brands wrote

Please don't call it RESTsomething. REST involves much more than exposing http methods. Just to avoid that in the future somebody complains about missing REST features. Remember, a little while ago whe had somebody complaining about URIParser not supporting sip uri's ;)

Out of curiosity, what else do you think a REST *transport layer* should support ?

Michael.

TCP is the transport layer, HTTP the application layer. Don't know what a REST *transport layer* is, but i can guess what your question is about.

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. Is it going to stop a programmer to modify data in an onGet? Will it stop the programmer spitting out URI's that point nowhere?

A class that uses fpWeb, talks directly to a Tdataset, implements the basic CRUD with GET,PUT,POST,DELETE and uses json,xml,... to create the reply would probably deserve the REST label.

Ludo

Ludo Brands wrote

TCP is the transport layer, HTTP the application layer. Don't know what a REST *transport layer* is, but i can guess what your question is about.

Well, I consider HTTP part of the the transport layer. The messages could be transported over SMTP, after all. But this is just name picking :-)

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.

Ok, that is simply an alternative to the current TFPWebDataModule which does not rely on part of the URL to determine the CRUD action, but uses the URL just to determine the resource, and the HTTP method to see which CRUD action needs to be performed.

That's easily done. It's about 5 lines of code in TFPWebDataModule: 1 for a "RESTFul" property, 4 to determine the action from the method if RESTFul is set to True.

Do you think this would be a useful addition ?

Michael.

That would indeed be a very good starting point for a REST implementation. In the few REST implementations I have seen, the uri is used to pass on the record identifier for the RUD action while, if I understand correctly, TFPWebDataModule gets the record identifier together with the data from a datainputadaptor. This will probaly need a customised datainputadaptor since a record identifier can be anything.
Currently I'm not involved in a REST project. Better get input from people actively working on it before implementing anything. There are so many implementation variations.

Ludo

Indeed.
In fact, the implementation should go in the web input adaptor.

Michael.

To be "RESTful" (I'm talking about HTTP), you do not pass the parameters of "GET,DELTE" etc.. as a parameter, but as part of the HTTP Protocol, that is:

GET /names HTTP/1.1
....

DELETE /names HTTP/1.1
....

etc...

As you know REST is an architecture, not just a set of classes or methods.

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 <http://www.sinatrarb.com/>. 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...

Sure you can do so at the moment ,but you will repeat your code or write way too general code for something like that. Having OnGet etc... provide easier way not to repeat yourself and even making the code much more readable and maintainable imho.

I Hope that is more clearer now.

Michael.

Ido

This is all understood.

But Ludo is right in that a REST implementation is more than just routing the HTTP method :-)

Michael.

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.

I started something at
http://code.google.com/p/luipack/source/browse/#svn%2Ftrunk%2Fluirest

It very initial. Did not get the time to finish. Maybe in september when i get more time...

Luiz