[racktables-users] Re: writing a restful API in php for Racktables

  • From: Ian Bettinger <ibettinger@xxxxxxxxx>
  • To: racktables-users@xxxxxxxxxxxxx
  • Date: Thu, 16 Aug 2012 11:36:23 -0700

That's up to Alexey, I assume.

I was originally writing it against 0.19.12, but am planning to
develop it against https://github.com/RackTables/racktables (master
branch) going forward.


On Thu, Aug 16, 2012 at 10:56 AM, Julson, Jim <jjulson@xxxxxxxxxxxxx> wrote:
> Is this for the current stable release 0.19.13?
>
> -----Original Message-----
> From: racktables-users-bounce@xxxxxxxxxxxxx 
> [mailto:racktables-users-bounce@xxxxxxxxxxxxx] On Behalf Of Ian Bettinger
> Sent: Thursday, August 16, 2012 11:50 AM
> To: racktables-users@xxxxxxxxxxxxx
> Subject: [racktables-users] Re: writing a restful API in php for Racktables
>
> Hi,
>
> For those interested I've forked the RackTables/racktables project and done a 
> bit more work on the API:
>
> https://github.com/ibettinger/racktables/blob/master/wwwroot/api.php
> https://github.com/ibettinger/racktables
>
> I'm working on (among other things) an edit_object_allocation method now, 
> which is somewhat tricky because of the way ophandler.php and it's supporting 
> functions expect data to come in from the HTML form on
>
> page=object
> tab=rackspace
> op=updateObjectAllocation
>
> ...anyway, as always interested in folks' questions / suggestions.
>
> Cheers,
> Ian
>
>
> On Wed, Aug 8, 2012 at 3:05 PM, Chubby Wl <chubbypama@xxxxxxxxx> wrote:
>> Ian,
>>
>> I just downloaded the skeleton code you attached to your email back in July.
>> It looks fantastic. I tried the few URL examples you posted using my
>> data and it worked.  Thanks for your work on this.  It's going to
>> benefit a lot of folks.
>>
>> I'm just new to racktables / open source development and am trying to
>> get up to speed quickly.
>> We actually need an api in short order and I'm trying to evaluate what
>> my options are.
>> I guess I'm debating whether or not I should:
>> -  create my own API of sorts to access RT data using an MVC
>> framework, strictly for internal use only.
>> - use your API,depending how far along you are.
>> - volunteer to help - depending on whether or not I have the skill
>> sets you need.
>>
>> Do you have any comments / thoughts?
>> Have you been posting your code somewhere?  I'd be curious to see what
>> types of changes you've implemented.
>>
>> Thanks for your time.
>>
>> cp.
>>
>>
>> On Fri, Jul 13, 2012 at 12:41 PM, Ian Bettinger <ibettinger@xxxxxxxxx>
>> wrote:
>>>
>>> Alexey,
>>>
>>> Thanks for the input. I've taken a first stab at a skeleton version
>>> of the api.php file, adding just a couple of methods for now.
>>>
>>> Can you take a look and see if this approach makes sense to you? I'm
>>> not totally familiar with RT's coding style, how you organize things,
>>> etc, so let me know what needs to change and I'll incorporate it
>>> going forward.
>>>
>>> Cheers,
>>> Ian
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 3, 2012 at 10:19 PM, Alexey Andriyanov <alan@xxxxxxxxxx>
>>> wrote:
>>> > 04.07.2012 02:53, Ian Bettinger пишет:
>>> >
>>> >
>>> >> I've been looking at the plugins system -- is there any way to use
>>> >> it and not get a fully rendered HTML UI? I'll need to respond to
>>> >> requests with a plain JSON/YAML page. The only way I could figure
>>> >> to do this would be to register a new operation that uses the
>>> >> page=file, tab=download to trigger the appropriate Content-Type:
>>> >> header in the "download" module.
>>> >
>>> >
>>> > You can install your handler to the default 'interface' module, and
>>> > then replace the Content-type header, clear the output buffer by
>>> > calling
>>> > ob_end_clean() until ob_get_level() returns 0, and call exit()
>>> > after rendering your result. But I agree, this method is not elegant.
>>> >
>>> >
>>> >> Assuming I haven't missed an easier way to circumvent the
>>> >> navigation rendering, maybe the best thing would be for me to
>>> >> create an api.php file at the same level as index.php and go
>>> >> forward with your plan otherwise. Might be easier to do the REST
>>> >> conversion later that way, as well.
>>> >
>>> > Yes, this could be a better idea.
>>> >
>>> >
>>> > --
>>> > Best regards,
>>> > Alexey
>>> >
>>> >
>>
>>
>
>
> The information contained in this e-mail message may be confidential and
> protected from disclosure.  If you are not the intended recipient, any
> dissemination, distribution or copying is strictly prohibited. If you
> think that you have received this e-mail message in error, please notify
> the sender immediately by replying to this message and then delete it
> from your system.
>

Other related posts: