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.
