Introducing vibe.d! SOAP .. REST?

[bls]

Am 30.04.2012 08:38, schrieb Sönke Ludwig:
> If you mean automatic generation of a REST interface for an existing D
> interface, then it's definitely planned. I can imagine a sloppy version
> where the HTTP method is always POST or can be POST/GET as desired by
> the client. But I would also like to have a more expressive version,
> where the HTTP method is inferred from the D method somehow and maybe it
> would also be possible to specify a sub path for each method.
>
> Sönke

Yes, this is what I am asking for. I think POST/GET is not enough.

Should be POST GET PUT DELETE

I would be fantastic if vibe.d can implement a REST SERVER following 
this guideline :

The JsonRestStore follows
RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt) whenever possible to 
define to interaction with server. JsonRestStore uses an HTTP GET 
request to retrieve data, a PUT request to change items, a DELETE 
request to delete items, and a POST request to create new items. It is 
recommended that the server follow a URL structure for resources:

     /{Table}/{id}

This URL will be used to retrieve items by identity and make 
modifications (PUT and DELETE). It is also recommended that a /{Table}/ 
URL is used to represent the collection of items for the store. When a 
query is performed, any query string is appended to the target URL to 
retrieve the results of the query. The JsonRestStore expects the results 
to be returned in an array (not in an object with an items property like 
some stores). The store will also POST to that URL to create new items.

When creating new items, the JsonRestStore will POST to the target URL 
for the store. If your server wants to assign the URL/location for the 
newly created item, it can do so by including a Location header in the 
response:

     Location: http://mysite.com/Table/newid

The server can also assign or change properties of the object (such an 
id or default values) in the response to a POST (or any other request), 
by simply returning the updated JSON representation of the item in the 
body of the response.

Note that in PHP, sometimes setting the Location will erroneously 
trigger a 302 status code which will cause JsonRestStore to fail. Per 
RFC 2616, the correct response to a POST that creates a new resource is 
to return a 201 status code with the Location header. In PHP, you must 
set the status code as well as the Location header if you want to avoid 
a 302 response.