Create RestPortal as alternative to WcfPortal

Create RestPortal as alternative to WcfPortal

Old forum URL: forums.lhotka.net/forums/t/12715.aspx


_pisees_ posted on Wednesday, August 06, 2014

I am exploring the idea of creating a RestPortal based on WcfPortal to simplify creating a Web API for HTML + Angular client. WcfPortal has quite a simple API: Create, Delete, Update, Fetch, which should be easy to duplicate in a Web API. Any thoughts on pros and cons of this? Any pointers on how could simplify project or roadblocks may encounter?

Thanks, Kurt

RockfordLhotka replied on Wednesday, August 06, 2014

You may want to look at the HttpProxy and host classes in 4.5.600. In ASP.NET 5 the host is a Web API endpoint, and in ASP.NET 4 it is an MVC controller (because Web API didn't yet do all the necessary threading stuff).

Technically this isn't 100% RESTful because the data portal itself isn't actually restful. The data portal transfers a self-describing binary payload from the client to the server, and the server processes that payload based on the data _inside_ the binary blob. REST says that the request should be processed based on the GET/POST/PUT/DELETE verb - but in the case of the data portal the "verb" is embedded in the data stream.

And in the data portal's case there is _always_ a resulting binary blob returned to the client. That resulting blob again is a self-describing payload containing success/failure information and possibly other data of use to the client.

As a result the HttpProxy only makes GET calls to the Web API end point, and always passes what should be viewed as binary blobs to/from the server.

In your case you'd want to pass JSON data to/from the service end point, but the basic concepts remain the same as HttpProxy.

_pisees_ replied on Wednesday, August 06, 2014

Thanks very much Rocky.

I am reviewing HttpPortal and it looks like I will have to modify implementation to work with JSON. That existing HttpPortal transfers binary payload for a .NET client, and not for JavaScript Client (like HTTP + Angular). Is that correct?

Because HttpPortal.InvokePortal use of MobileFormatter will not deserialize JSON to a CriteriaRequest

// var request = MobileFormatter.Deserialize(buffer.ToArray());

For example the following from client

[POST] http://[server]/Mvc5AppServer/api/DataPortal?operation=fetch

[PAYLOAD]{"typeName":"Library.Net.Library.CustomerEdit","criteriaData":null,"principal":null,"globalContext":null,"clientContext":null,"clientCulture":"","clientUICulture":"","isBusy":false,"isSelfBusy":false}

 -Kurt

 

ajj3085 replied on Tuesday, August 12, 2014

I think you're going about this the wrong way.  You should not attempt to deserialize a Csla object directly as the result of a web service call.  Instead you should map your Csla object to other objects (I'll call them DTOs) that represents the request / response data.  Please see this page (it also includes a link to a forum post which has a deeper explaination):  http://www.lhotka.net/cslanet/faq/ObjectsAsServiceContract.ashx

Also, I don't think that POST http://[server]/Mvc5AppServer/api/DataPortal?operation=fetch would be considered restful.

_pisees_ replied on Saturday, August 23, 2014

As I understand, CSLA supports clients like Silverlight, WPF, Windows Forms by supplying client-side logic that leverages mobile objects that run on the client. There is no need to create DTO because the Framework takes care of creating these mobile objects which supply client-side data binding, validation etc., logic for communicating with the server and sterilizing data needed. I am trying to do the same thing but wit HTML+Angular+JSON -- in effect support a new non .NET client. I realize that creating all the client-side functionality in JavaScript may be a large project, but my questions are related to how much I could achieve by modifying HttpPortal. 

 

Any thoughts appreciated,

Copyright (c) Marimer LLC