Hello!

Use method WServer::addResource() to add global resourse to your
server. This resource will not be bound to any particular session.

Use method Http::Request::getParameter of request object, passed to
WResource::handleRequest. This method can be used to get values of GET
parameters ("start" and "stop" in your example).


On Fri, Dec 7, 2012 at 6:05 AM, Craig Miller
<craig.mil...@spatialminds.com> wrote:
> I'm trying to implement a very simple RESTFul API on top of Wt.  I read a 
> couple emails from Koen on the mailing list archives (pasted below for 
> reference), but the use case there required a tie to the session (adds 
> session ID to url) which makes the API no longer RESTFul.
>
> I have a WResource derived class implemented that generates the response (CSV 
> in this case) I want to generate.  I'm hoping to put it at a fixed URL w/o 
> being tied to a session so it can be hit at anytime.  E.g. 
> http://myserver.com/restapi/csv?start=1&end=2
>
> Any suggestions on how to best achieve this?
>
> Thanks!
> Craig
>
> ----
> Email from Koen on the mailing list:
>
> Hey Maurice,
>
> 2010/3/3 Koen Deforche <k...@emweb.be>:
>> Hey Maurice,
>>
>> 2010/3/3 Maurice Gittens <mainmanmauri...@gmail.com>:
>>> Hi,
>>>
>>> I'd like to use the Witty Application Server to serve not only a Witty
>>> Application
>>> but also to serve JSON data as a restful data service.
>>>
>>> Consequently I will need to handle HTTP POST, DELETE and PUT methods
>>> in the My Wt application server.
>>>
>>> I would like to allow users logged in via a valid Wt session access to my
>>> Restful Json data stores.
>>> What is the recommended way to do this with Wt?
>>
>> Currently, you can already GET and POST to a WResource. Providing
>> support for DELETE and PUT is a logical extension. You can also
>> already access the raw input stream (that was POST'ed or PUT) when it
>> is not something that can be parsed by the CGI Parser from
>> Http::Request::in().
>>
>> The missing parts are:
>>  - provide support for DELETE and PUT commands in the httpd and check
>> that it works for the fastcgi connector.
>>  - expose information on the command in Http::Request (GET, POST,
>> DELETE or PUT).
>
> I've implemented this now and so expect this in public git sometime next week.
>
>> Currently a WResource will have a random (auto-generated) URL. You
>> probably want a predictable URL for your service, and this would also
>> require a small extension to WResource (setInternalPath()) together
>> with support in our web controller.
>
> I've implemented this as well. Note that there will still be a session
> appended to the path.
>
> Regards,
> koen
>
>
> Craig Miller
> http://spatialminds.com
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest

Reply via email to