WebServiceClientMeetingAug2013

Web Services consumption meeting, Aug 27, 2013

Attendees: Milan, David, Petr J

  • Use case 1: URL as a starting point, no extra information about the service
  • Cache service metadata locally. Could it be eventually shared among users?
  • UI to register in Web Services node - does not need to be explicit, could be implicitly done by the IDE as a byproduct of the REST client generation task
  • Synchronization of code with metadata after initial code generation is a non-goal
  • Would be nice to be able to edit metadata after it's cached
  • Knockout has a mapping plugin that could be useful?
  • Framework for binding (Knockout, Angular) may be different from the framework for REST call (jQuery, Angular)
  • Bundled web service metadata under Web Services node - what information to store?
  • Use case 2: Calling a web service that has existing metadata (adheres to Oracle REST standard, or provides JSON schema)
  • Jersey will likely in the future generate JSON schema for all services. JSON Binding standard (JSR) being developed by Blaise Doughan (EclipseLink team)
  • When we reimplement the Web Service node to drop WADL metadata, Java REST client generation will stop working - that's ok, acceptable regression
  • Should split Web Services node to SOAP Services and REST Services (Resources)
  • Kill WADL for REST, replace with our own metadata (possibly JSON schema directly)
  • Current REST Client wizard that generates Backbone code should stay intact - create a new wizard next to it
  • Main task should be REST Client generation for Knockout
  • Could we just implement this wizard and postpone the new REST services node to later, to save time?
  • Cache response from REST call to enable offline development?
  • Sometimes query params are very important - but the ability to specify the URL is sufficient for this use case
  • Need a way to specify API key - must have requirement
  • Create a new module for the new wizard, that can be easily added/removed from the build e.g. web.client.rest2 (web.client.rest is already taken, though we may want to renamed that to web.client.backbone to free up the web.client.rest name)
  • Should explore the Postman REST Client plugin: https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en
  • Should explore the REST testing UI in WebStorm
  • Should we also generate UI code that displays the result? That should be optional.

Summary

  • Milan will work on the REST client wizard that generates Knockout code
  • Initially focus on the case with no additional metadata, just URL is the input
  • Ability to use API key is a requirement
  • Change Web Services node to just SOAP services for 8.0, REST Services node will be added if it's done in time
  • REST services node UI to be added next, REST client wizard code should be prepared for it
  • Separate module for now, could be added to 8.0 release if it's ready
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo