GoogleCodeExporter
commented
9 years ago Hi Mikael,
First of all, thanks for you're interest in this project :)
REST support this is something that I've been thinking about as well and I've
already started to lay down the framework as can be seen in my IRest* service
classes here:
http://code.google.com/p/servicestack/source/browse/#svn/trunk/Common/ServiceSta
ck.Interfaces/ServiceStack.ServiceHost
In there I have interface classes allowing you to specify GET, POST, PUT,
DELETE Http Methods. There is no 'LIST' defined in the spec per-se but you
should still be able to differentiate its intent based on the GET request (i.e.
'Users' vs 'Users/1'). At the moment there is preliminary support for it where
if a service implemented both IService[T].Execute() and IRestService[T].Get()
then GET requests would invoke the 'IRestService[T].Get()' otherwise if
it didn't exist would fall back onto the default 'IService[T].Execute()' the
same with the other HTTP METHODS. Now unfortunately full REST support is going
to require a lot more than this.
For some background info, the 'Service Stack spirit' if you like, are for
requests to be strongly-typed, convention-based, with predictable behaviour
which allows us to provide a simpler API and a lot of functionality for free
without unnecessary configuration whilst still providing good performance. The
challenge therefore is to map the REST world predictably onto a Service Stack
request.
If the REST request was only 1 level deep then this can quickly be applied to a
'ServiceStack request', i.e.
where I could automatically provide support for say:
GET 'Users' => '/SyncReply/Users'
GET 'Users/1' => '/SyncReply/Users?Id=1'
Even at this level, the expected response is 'UsersResponse' which as it needs
to support for both a list and a single 'User' will probably look like:
{{{
public class UsersResponse
{
public List<User> Users { get; set; }
}
}}}
When you go any deeper than that then you are effectively changing the service
you're calling, i.e.
GET 'Users/5/Reports' => '/SyncReply/Reports'
GET 'Users/5/Reports/1' => '/SyncReply/Reports?Id=1&UserId=5'
Now there a clean way you can achieve this today is through 'URL re-writing'
where you would literally just rewrite the query-string to achieve the above
behaviour. The problem with this is the re-writing logic is kept outside of
code in an external web servers configuration file (i.e. nginx or apache),
which is not great productivity win for iterative development. I could also
potentially provide the ability to define your own rules but I'm not 100% sure
what the API would look like (which I would like to know your thoughts on), I
am considering whether it is worth while re-using the URL Routing that comes as
part of ASP.NET MVC e.g:
http://weblogs.asp.net/scottgu/archive/2007/12/03/asp-net-mvc-framework-part-2-u
rl-routing.aspx
Which while we're on the subject, you can kind of in a round-about way build
REST services (well JSON at least) using ASP.NET MVC which as its open source
and included with Mono (Just thought you should know).
I'm still in two minds about whether to go for a new but completely pure /Rest/
endpoint or whether to modify the existing ones to provide richer REST
functionality out of the box. I prefer to modify the existing ones as it will
enrich them with more functionality for free, except as it stands they kind of
violate the 'Accept/Content-Type' HTTP headers as the format is embedded in the
request.
I am more than happy to accept patches the only criteria is that it is a
generic solution to cover most use-cases and it's in-line with 'the Service
Stack spirit' :)
To start the ball rolling, and expedite REST support in ServiceStack it would
be good if you could provide the DTO definition (i.e. request and response
DataContract's) and preferred REST URL's of some of your proposed services
so I can ensure that it can be supported?
As a final word of caution, I should warn you that ServiceStack is still
reliant on Mono's WCF support for SOAP 1.1/1.2 web services, their Base Class
Library DataContractSerailizer for Xml services as well as their
JsonDataContractSerailizer for the JSON ones. In the past they haven't been as
complete as their .NET equivalents and you generally will have to go with the
latest version of Mono to get the best support. They are pretty good
with bug reports so it's quite likely they will fix most issues promptly.
Although as I wanted full source control for a web service implementation that
I can ensure works reliably cross-platform on .NET to .NET endpoints, I ended
up inventing a hybrid JSON + CSV serialization format (i.e. JSV Format)
which has advantages over the above endpoints and you can read more about here:
http://www.servicestack.net/mythz_blog/?p=176
When @marcgravell has finished his rewrite in protobuf-net we'll have another
fully managed/controlled serialization option that as a primary goal will also
work cross-platform.
- DemisOriginal comment by demis.be...@gmail.com on 27 Apr 2010 at 9:40
Original issue reported on code.google.com by
wikman.mikael@gmail.comon 27 Apr 2010 at 6:22