M
mjacobs
Guest
I agree wholeheartedly. The JSDOs provide great value for applications whose primarily use-case is CRUD operations and RPC like remote calls. Like SOAP, the properties of the transport the JSDOs uses are hidden so the application code is not bound to any single transport type such as http. The initial rollout of JSDOs chose to tunnel through RESTful http (i.e. the REST adapter) because it provided the best value for the greatest number of use-cases. Doesn't mean that http is the only transport that will ever be used between your mobile device and the AppServer's service interface. There are use cases when using true RESTful communications is the right thing to do because your AppServer ABL application wants/needs to take low level control of the http transport's properties. That is where the REST adapter's full feature set is useful because it allows your AppServer direct access to most aspects of http via parameters in ABL procedures and class methods. But there are limitations in that the client must communicate directly with the AppServer with only a web server (REST adapter) in the middle. There is nothing stopping you from creating a Mobile project that employes both Mobile and RESTful service interfaces, if that is truly necessary. The majority of the time it not necessary. You just cannot combine the features of both into the same API (today).
Continue reading...
Continue reading...