I think the primary reason to use the REST APIs over Connect or Forge is when you’re building an app that integrates with Jira but is not intended to live within the Jira app UI itself. Connect seems to have a higher overhead and set of requirements by comparison, but perhaps it is just not explained clearly in the overview documentation or I’m misunderstanding?
At the moment, Forge and Connect definitely aren’t in the “just copy your secret at go” state, so I agree with you in terms of where things are at today – it isn’t great that you need to choose between a simple starting experience and a whole host of useful functionality (like webhooks) when you’re building an integration.
This is something that we definitely want to make better. How we’re looking at things right now, I think it’s more likely we’ll achieve this through evolving Forge/OAuth 2.0 so that they become the go-to for all use cases, and making it as simple as possible to get started regardless of what you’re building. This will allow us to get to a better experience faster than trying to add equivalent functionality to each of basic auth, OAuth 1.0a apps, OAuth 2.0 apps, Connect, Forge. The sooner we consolidate, the less likelihood developers will have to “paradigm shift” to an entirely new platform/framework when they need a particular piece of functionality (again, like webhooks).
Of the 3 basic auth seems to get the closest, but the body content I send over does not seem to get read by the API call and I get an error back that name and url need to be provided even though they are.
I’ve heard back from the team and confirmed that listening for webhooks is a feature of Connect only. If you’re experiencing what looks like a bug with basic though, feel free to shoot me over the fine-grained details of that and I’ll go ahead and create a bug for you.
There are a few other areas where OAuth 2.0 is incomplete where falling back to OAuth 1.0a or Basic Auth “works”
If possible, would you be able to reply here/shoot me a DM enumerating each of these? It would be incredibly helpful for the team, for the reason I’m about to explain next.
While I have not looked through every API, it feels like things are so close to just working with OAuth 2.0, but these obstacles likely cost everyone trying to do an integration with OAuth 2.0 a lot of pain and wasted time.
Mate, couldn’t agree more. It’s certainly what we’re working towards, with progress made already and plenty more to come (i.e. I know we’re quite close to having full parity in terms of the APIs you can call via OAuth 2). I really appreciate the time you and everyone else is taking to outline exactly what’s missing and what’s important, it’s definitely helping us get there faster 