Hi All, We try to use the RTx-REST v2 plugin. We modified the source of RT 4.2 with the following: https://github.com/bestpractical/rt/compare/4.2;support-rest-v2 then installed the plugin and tried to use the REST interface with curl, but we got "internal server error" message. In the error log we have:
[error] [client 1.2.3.4] You must pass in a resource for this Web::Machine at /usr/local/share/perl/5.14.2/Web/Machine.pm line 29.\n\tWeb::Machine::new('Web::Machine', 'resource', 'RTx::REST::Resource::Queue') called at /opt/rt4/local/plugins/RTx-REST/lib/RTx/REST.pm line 176\n\tRTx::REST::resource('Queue') called at /opt/rt4/local/plugins/RTx-REST/lib/RTx/REST.pm ... then [error] [client 1.2.3.4] Attempt to reload RTx/REST/Resource/Queue.pm aborted.\nCompilation failed in require at /usr/local/share/perl/5.14.2/Module/Runtime.pm line 317.\n Could you give us a short hint how to get through this problem? Thanks, Bekeny On Thu, Mar 13, 2014 at 9:16 AM, <akos.to...@docca.hu> wrote: > Hello Alex, > Thank you for all the infos. So: > - we would join improving REST 2.0 (rtx-rest), > - we would develope an angularjs (or backbone.js) client. > > I hope our work would be useful for all the RT community. > > > > Hello Community, > If anyone has angularJS or backbone.js competency and could join us (any > way), just let us know please. > > Thanks, > > Ákos > > > > On Wed, Mar 12, 2014 at 8:33 PM, Alex Vandiver > <ale...@bestpractical.com>wrote: > >> On Thu, 2014-03-06 at 17:21 +0100, akos.to...@docca.hu wrote: >> > This is some kind of request for comment. Please, feel free to give us >> > advice, support, ideas. If you have similar effort, if you know any >> > solution that makes this problems causeless, let us know please! >> >> Best Practical is always interested in contributions from the community >> which improve the product. As it happens, our focus for RT 4.4 is >> planned to include a concentration on the UI, as well as a rewrite of >> the REST API. >> >> For RT 4.2, we held to our previous restrictions that the entirety of >> the UI needed to be accessible to users without JS enabled. With >> JS-based UIs sufficiently prevalent now, it is our intent with RT 4.4 >> that JS will be a required part of the UI. >> >> That being said, we do not intend to write the entirety of the UI in JS, >> as a thin wrapper around back-end APIs. Such a rewrite would be >> extremely time-intensive, and unlikely to be able to duplicate all of >> the features of the current server-side templating solution. >> >> However, we're quite interested in improving the REST API. The 1.0 REST >> API was written well before the advent of JSON, and indeed before the >> concept of "REST APIs" had begun to be commonplace -- as such, it has a >> number of very odd design decisions that hinder extensibility. Because >> of this, we are uninterested in expanding on it, but are more focused on >> providing a new implementation which is based on modern assumptions of >> how REST APIs should function. >> >> We currently have an initial sketch of a REST 2.0 already partially >> completed, with the aim to release it as an extension for RT 4.2, in >> core in RT 4.4, and remove REST 1.0 thereafter. It is now published at >> https://github.com/bestpractical/rtx-rest -- it also requires the RT >> branch https://github.com/bestpractical/rt/tree/4.2/support-rest-v2 >> >> Bear in mind that this is highly experimental; we do _not_ suggest its >> use apart from developers working on it. It is in no way >> production-ready. As we are aware it is lacking in features, pull >> requests or patches welcome; simple bug reports are not helpful at this >> juncture. >> >> - Alex >> >> >> >> -- >> RT Training London, March 19-20 and Dallas May 20-21 >> http://bestpractical.com/training >> > > > -- > RT Training London, March 19-20 and Dallas May 20-21 > http://bestpractical.com/training >
-- RT Training - Dallas May 20-21 http://bestpractical.com/training