While this is a good hack for MVC.NET it is NOT REST.

REST ALWAYS has GET (Read), POST (insert), PUT (update) and DELETE functions that are called.

They are ALWAYS of the correct content type and request type in HTTP and ALWAYS follow specific rules.

If I wanted this to just work with MVC.net I'd use Infragistics (or anyone else's) mvc.net controls. There would essentially no reason to use a jquery based library because every mvc.net library I have ever seen uses jquery and works against MVC's anitquated web services and/or AJAX calls.

However THE STANDARD is REST + JSON. All libraries should follow this pattern. (i.e. if you were to use these controls in RoR then you would have to follow this pattern, because this is how it's done. Same with most other current languages.

That means that Updates, INSERTS and Deletes must be sent to their own endpoints. I'm obviously not going to write a wrapper in mvc.net to call REST services nor should that be expected given what jquery controls are all about.

Further, mvc.net 4 includes Web API which is fully restful and follows all of the rules as well.  Again this is the defacto standard and is taking over rather quickly from SOAP web services.

Thus I expected a REST data source that can work in batch mode as well as single object mode.  It should POST with a json array in batch and a single json object in non-batch (i.e. JSON.stringify()) for inserted records that need to be persisted, PUT in the same manner for updates to be persisted and send a list of IDs as parameters on the URL as described for deletes.

The request type should be set appropriately for each type of request.

My question is simply: Is this possible with Infragistics jquery or is it completely bound to mvc.net for some odd reason?

And if it's possible, what's the timeline for a true REST data source? (I would have expected that like Kendo it would have come with one out of the box because as I said, this is the standard for anything jquery.)

I'm trying to decide if I'm wasting my time with the infragistics controls or if it's worth pursuing. This is the one major roadblock and a surprising one that that.

Hi,

Thanks for the feedback. I think there are two different topics you are referring to, one is "dependence on ASP.NET MVC" - which is definitely not the case, you can set updateUrl to any service you like, and the posted content is JSON. You can use any server-side backend technology of your choice (PHP, NodeJS, RoR, etc.) , as long as you deserialize the transaction log JSON. 

The second one is about supporting RESTful CRUD services out of the box - you are absolutely right this is not the case at the moment. We will consider adding this in the backlog of the product for a future Service or Volume release.

In the meantime, you can also  iterate over the transaction log on the client-side, and invoke a separate CREATE / EDIT / DELETE request, assuming you have the URLs , as a workaround. This should be pretty straightforward to do, i will follow up with a sample about how to do this. 

Thanks again,

Angel

Thanks!

If you could do so and do it in a way that I can create some sort of method that I can hook up at creation that will automatically do this without me having to do it on every single data source that would be great.

Obviously having hundreds if not thousands of these in the project there will be a lot of potential for error.

I would suggest that given the landscape and how fast everyone is moving to REST that this needs to be VERY HIGH priority on your development list. Anyone with a REST service is going to expect this. (i.e. everyone on RoR and anyone using mvc.net 4 shortly among almost all others doing new projects on any platform)

FWIW, I'd very much like to see a standalone oData example with igHierarchicalGrid that can do oData CRUD operations on both the main level and child columnLayouts.  All the current oData examples are read-only.  Any chance someone could whip one up?

It's absolutely not as simple was WCF Data-Services.

Web API handles things VERY much differently and the writting is on the wall that WCF Data-Services is on the way out.

Web API + knockout + upshot = RIA for javascript and is the Microsoft way going forward. It is also the way that MS is going to support for standard REST services even if you don't use upshot. (which is crippled because it can't work against non-entities and doesn't support projections so it wastes resources by doing SELECT * on everything!.

Hence any implementation needs to work on true REST services. It needs to also be able to work on WCF Data-Services for backwards compatibility.

OData relies on REST. The most obvious of this is the GET, but it also POSTs Inserts, PUTS updates, AND DELETES deletes.

OData burries the actual data in the response because of meta data that is required for MS's change tracking and strong typing in Silverlight (and now upshot) but it's just JSON arrays. Same for the POSTS, AND PUTS.

Where every one of your competitors is getting it wrong is DELETE. If you get all of these right and can handle WebAPI propertly (which is the closest of all of them to true rest) and RoR's out of the box functionality you'll really be rolling.

A DELETE request is always done in the URI. That is, the KEY is passed as a parameter.  But more so, a batch can still be done with DELETE contrary to a lot of people's assertions. This is the valid, RFC standards compliant way to do a batch delete

<someurl>/delete?ID=5&ID=7&ID=9&ID10

That is, repeat the name of the Key and pass the values. In WebAPI and WCF this will be handled by the parameter on the Delete function being IEnumerable<KeyType>. Similar is also supported in other languages.

By implementing it this way and handling both Odata get return syntax and WebAPI pure array or single object return syntax, and post/puting pure json arrays you'll have rest done right with full Odata support as well.

Combine that with enabling direct knockout binding on your editors when not in a grid that works, and you'll have a killer product.

I'm more than happy to test out early code for you, as I have a lot of experience (unfortunately) making this stuff work and ensure that it's correct.

Thanks for the valuable feedback! :)

AFAIK, the OData itself doesn't define anything specific to REST, it's only defining how entities (resources) are being addressed, and how the URL should be constructed, in order to perform paging, sorting, filtering, querying (lazy /deferred loading), and so on. We do support OData in that sense, and we have a sample using the Hierarchical grid. Once REST support comes out of the box, it will and should work with the OData way of addressing resources, for sure. 

I've started to work on a REST sample - meaning the REST API itself, as defined by RFCs, but haven't got a chance to complete it.

Also FYI, we have added this feature as top priority for our next release - 12.2.

Hope it helps,  and again, thanks for sharing your thought guys - it really helps us improve the product.

Angel

According to support it's not possible without using their hack.

Unfortunately it appears that Infragistics jquery is not ready for any REST applications, Odata or otherwise. (even though it clearly shows in the graphic about the data source that it does support REST)

I gotta wonder why so many companies will eagarly show you read, but can't get full CRUD right with REST. (i.e. every single one that does sort of support REST out there doesn't get deletes right and violates RFC rules and posts data to the body of DELETE, which isn't allowed, all parameters must be in the URI)

Infragistics this is your opportunity to shine if you get this right and give us a truly REST service that handles things correctly.