Best Method for Exposing a Subset of the REST Functionality

Jul 7, 2010 at 5:35 PM

I am attempting to only expose a subset of the REST functionality provided within the DataTransfer project generated by this tool but I am not sure of how to do this without manually modifying the main Rest class. Basically, I only want to expose GET functionality to some users yet also allow PUT functionality for other users that are authenticated so I am trying to break out the overall REST functionality into multiple service applications. This is fairly simple to do in the WCFService project as I just created a new WCF application and referenced the interface provided by the generated project. However, there is no interface in the case of the REST functionality. Do you have any suggestions for how to do this without interfering with the code generation tools? Thanks!

Jul 7, 2010 at 6:40 PM

Update: I came up with a solution that seems to work fairly well. I simply created a new service and implemented a similar service host type as in your DataService project. I then created an instance of the "Rest" class within my service class and used this instance to access the functionality I wanted to expose. However, I ran into one catch. All of the methods in the the Rest class are private! Is there a reason for this or could you make these methods public in the next release? Thanks!

Coordinator
Jul 12, 2010 at 1:19 AM

Can you post a specific example of what methods you wish to make public. I will look into dealing with that next week.

Jul 12, 2010 at 12:06 PM

What I am trying to accomplish is to break up the overall REST service into a set of REST services (each of which expose a subset of the overall REST service functionality). For example, I may want to expose all of the GET methods to some clients yet expose some of the PUT methods to other clients. I may also not want other clients to know about certain tables in my DB so I may only want specific clients to GET or PUT from specific tables (i.e. specific REST methods). Does this make sense? So in order to do this, I have created my own well-defined REST service that wraps your generated REST service functionality. That way I can control what each sub-service is capable of providing. I have tried to provide a simple example below. In this example, I have a DB that stores User information, Location information, Employment information, etc... However, I only want to expose the ability to request the current User list via REST.

The main User service implementation is shown below...

[assembly: ContractNamespace("", ClrNamespace = "MyCompany.MyProject.REST")]
namespace MyCompany.MyProject.REST
{
    [ServiceBehavior(IncludeExceptionDetailInFaults = true, InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]
    public class MyUserService : IMyUserService
    {
        // The full REST service provided via nHydrate...
        private readonly Rest _RestService;

        public MyUserService()
        {
            _RestService = new Rest();
        }

        #region IMyUserService Members

        List<UserDTO> IMyUserService.UserListXML()
        {
            return _RestService.UserListXML();
        }

        #endregion
    }
}

The User service interface is shown below...

namespace MyCompany.MyProject.REST
{
    [ServiceContract]
    public interface IMyUserService
    {
        #region User Select All

        [WebHelp(Comment = "Returns a list of User objects to the user.")]
        [WebGet(UriTemplate = "UserList/?format=xml", ResponseFormat = WebMessageFormat.Xml)]
        [OperationContract]
        List<UserDTO> UserListXML();

        #endregion
    }
}

The use of the interface is not required but shown here for demonstration purposes only.