Is a REST Server possible?

[spot1701]

Excuse my ignorance, but has anyone had experience of using Nettalk for a REST server instead of a SOAP server.
Is it possible?

How could I tell the difference between a PUT GET POST and DELETE request?

[Bruce]

Hi Bryan,

my answer started getting a bit complicated, so I've tweaked the code for the next build to simplify it a bit. The rest of this answer applies to 6.39 (or later).

So the short answer is "yes". You can build a RESTful interface using the WebServer.

The first thing you'll need to worry about is getting the "verb". This is stored for you in
p_web.RequestMethodType
and is one of
NetWebServer_NOTDETERMINED            equate(0)
NetWebServer_POST                     equate(1)
NetWebServer_GET                      equate(2)
NetWebServer_PUT                      equate(3)
NetWebServer_DELETE                   equate(4)

Let's say you make a procedure based on NetWebPage. the requests (obviously using that URL) get fed to that page. Inside the page you can test the verb, and then "do" whatever it is you need to do.

One caveat - I'm not sure what techniques are used to pass additional parameters to the PUT or DELETE. For now I'm assuming they'll be part of the URL (like a GET) not in the body (like a POST) but I think they could be either way. In the long run I think some more work is necessary on my side to cope with all the flavors here.

Cheers
Bruce

[spot1701]

Thanks for that. I can make a start now

[bshields]

Hi Bruce,

Can i also have the following:

Net:WebClientPropFind
Net:WebClientReport
Net:WebClientPatch

They are needed for Google APIs (and CardDAV/WebDAV). Then i can remove my hack.

Regards
Bill

[bshields]

Hi,

At the risk of stating the obvious, here is a little more info on RESTful stuff regarding PUTs and DELETEs.

For a service to be RESTful no parameters should be passed in the URL (although it is technically fine to do so, it violates the idea of a RESTful service).

The URI should be used to identify the resouce eg:

http://127.0.0.1/media/{customerid}/{photoid}

not

http://127.0.0.1/DeletePhoto?customerid={customerid}&photoid={photoid}

But this is just for RESTful stuff.

For PUT the thing being updated should be identified by the URI (as above) and the "data" be inside the body.

I have seen google expect additional information regarding a delete (for concurrency control) to be placed in the request header.

Regards
Bill

[Bruce]

Thanks for the info on PUT Bill. I'll tweak that a bit so it gets parsed like a POST.

>> For a service to be RESTful no parameters should be passed in the URL (although it is technically fine to do so, it violates the idea of a RESTful service).

yeah - this is where things get too pedantic for my tastes. But hey, either way will work fine, so I don't particularly care what folk do <g>.

Cheers
Bruce

[Bruce]

Hi Bill,

>> Can i also have the following:

I missed the post above about this. Can you tell me more though please? I'm not sure I'm following 100% with you with regard to what these properties are. (Also are these _client_ or _server_ properties?)

cheers
Bruce

[bshields]

Hi Bruce,

As far as I can see they appear to work the same as POST, but they are just verbs (or methods) that indicate the "action" desired.

In the event we are trying to talk to a web service we need the functionality as part of NetWebClient so we could optionally set the verb (but its likely to work exactly as a POST) and in the event we need to build a web server that supports these additional actions/verbs we'd need to be able to query the NetWebServer/Worker to see the verb used.

I've only seen them as part of web services (or old school style web services webDAV, cardDAV, calDAV).

It just helps the server decide what action to perform, rather than the natural of how request should be processed.

Regards
Bill

[Bruce]

mentioned elsewhere, but just to keep this thread up to date - build 7.27 contained support for a lot more HTTP verbs.