As someone who has been trying to use the REST2 API to automate certain kinds of workflows that we need to do and expose in external systems, it is a bit frustrating that a lot of the features I need just don’t work or awkwardly require me to do things via the V1 API. Sometimes these actions making things take 10x more API calls because of how the existing API works.
That said, I’m thankful that the community has done the work to fill in a lot of these major gaps. What makes me a little sad is that these fixes and features are not being reviewed and merged, with no comment on them at all from BPS.
Not to mention there are minor documentation patches which were actually written by someone at BPS and even those haven’t been merged (I’m not 100% sure if they are all that useful though) which makes me wonder how important or supported the REST2 API even is:
Essentially, I’d just like some visibility on what is happening here, and I bet I’m not the only one. Are these pull requests not up to scratch, was some process not followed, is this low priority because it isn’t ‘paid feature’ work? Does BPS care about the REST2 API at all?
Right now anyone who wants to use the features these pull requests fix or add, we have to roll our own fork and maintain that, which in the long term doesn’t really help anyone, but it is what we are doing now.
So please, help the people who are trying to help with those patches, and lets make the REST2 API actually fantastic!
I can understand your frustration - without some level of transparency it can feel like nothing is happening.
I cannot comment on BPS’s plan for REST2, but there are lots of factors that go into what they work on. One factor is their (paying) customers.
The university that I work for regularly hires BPS to make feature improvements to RT that we (the university) care about. So BPS has business obligations to their customers who have contracts with them. We are not their only customers. I’m sure they have lots of obligations and only a limited number of engineers. There are only so many hours in a day.
BPS is well aware that REST2 is an important component of future RT releases - they want it to be great.
I guess you have some options:
Patiently work within the community channels they provide:
I mostly just don’t want to start writing code around APIs that will change. Because until they merge a pull request, that API (on any fork) may not be what the final design will end up.
I’m working on writing a new python library for talking to the RT v2 API, as well as a command line interface which uses that library. This would be useful to more than just myself and the organisation I work for, but I can’t continue easily because I don’t know which parts of the API and the pull requests I can trust.
Right now the library I’m writing will only be applicable to our fork of the rest2 API.
The existing API is in a lot of ways lacking, and people have done some of the work getting a lot of the missing features into place, all that is needed is a few days of review and testing.
An example of a missing feature, right now if I wanted to list all the names for all of a given record type (lets say queues), I have to query the get all API, and then use the IDs I get back to query each resource to get its name. That is an O(n) operation that becomes O(1) by allowing us to include fields in the get all API call. This also works when searching. That’s HUGE, and there is a pull request for it, with other really useful pull requests like proper attachment upload handling (which is even in the BSP Todo list).
I fully understand that they are busy, and the expectations of paid client work vs opensource but this benefits them and RT itself since their existing customers also would get these features. If they have too much paid work then maybe they should consider bringing external reviewers into the project they can trust or who have done a lot of work already. This is a common practice for opensource projects, and they don’t have to be the only ones maintaining it. Share the workload! Nothing stops them from still doing the paid work, but I bet you there are contributors to RT willing to help review patches.
That fosters a community, because otherwise we are all waiting on just them to review code based on their internal priorities and paid work, which essentially defeats a lot of the amazing benefits of being opensource at all.
Regarding “paid client work vs opensource” is a bit misguided. I don’t know how much of BPS’s work (for other customers) is proprietary, but nearly everything we (the university I work for) has paid BPS to write has been put into core RT. The code that they’ve written for us that isn’t part of core RT are still RT modules that have a free software license.
So, the community (which includes you, me, and other customers) do benefit from the work we pay BPS to do - just as we (customers) benefit from the work that the community (which includes you and I) does. It is very symbiotic.
I wouldn’t assume that the work that BPS is paid to do doesn’t benefit RT or their (other) existing customers.
I don’t want to get into a big discussion about things (or argue back and forth), but I think we need to assume good faith and realize it is harder to execute certain things - like finding a trusted community member to give merge privileges to so they can vet PRs - than we think it is.
Lastly, github allows users to comment on PRs. People who are interested in reviewing PRs could cherry pick the commit, test it out in their local RT environment, and comment back on the PR thread.
Regarding “paid client work vs opensource” is a bit misguided. I don’t know how much of BPS’s work (for other customers) is proprietary, but nearly everything we (the university I work for) has paid BPS to write has been put into core RT. The code that they’ve written for us that isn’t part of core RT are still RT modules that have a free software license.
So, the community (which includes you, me, and other customers) do benefit from the work we pay BPS to do - just as we (customers) benefit from the work that the community (which includes you and I) does. It is very symbiotic.
Sorry that wasn’t what I was implying at all! I’m willing to bet all (or almost all) of their paid work is just adding features to core. Which of course benefits everyone. I doubt they have any nefarious intentions, and from what I can tell everything is opensource.
My main point is that in a lot of opensource projects I have seen which are mostly controlled by one company, they end up the driving force behind all the choices and code which is merged. This can be a double edged sword, both good (single minded direction and planning), but lack of willingness to do things outside of their plan even if beneficial.
I mostly work in opensource, but normally community driven opensource (no single owner), which has its own range of issues, but it tends to foster a more balanced approach to work the community is contributing, and work that some company has paid one of the contributing parties to work on.
My gripe is, the RT REST2 API was released in 2017 in an unfinished state likely because that’s about as much of an API as some paid client or internally planned work needed, and still isn’t finished in 2019, despite some community pull requests the fill in most of the major gaps. It shouldn’t need someone to pay to have that reviewed.
So as an update, we’re maintaining our own fork of the RT REST2 extension right now with a lot of the pull requests tested and used ourselves, and I’m just building our python client against that. I’ll comment on the pull requests we are using to try and get someone to look at them, but I don’t have high hopes.
Right now our RT is using:
But we will have a generic non-versioned branch for the latest version soon as well (will update).
Then the client I am working on is currently available on pypi, but again relies on our fork. Some basic functionality will work against the official extension, but not all until those pull requests are actually merged.
My intention is to also build a CLI into that client which uses the client itself to talk to the V2 API.
