Skip to end of metadata
Go to start of metadata

Way back in October 2010 we released JIRA 4.2 and the first real REST API for JIRA. We continued to add to it over 4.3 and 4.4. By February 2012 we felt confident in the direction our REST API was going and removed the alpha and beta labels from it in JIRA 5.0. The scope of the API continued to expand over subsequent releases: 5.1, 5.2, and now 6.0. With the continued growth of our REST APIs we've made the decision to officially deprecate the SOAP and XML-RPC remote APIs.

Why

Deprecating SOAP and XML-RPC means that developers have a clear and consistent message from us about how they should be interacting with JIRA remotely. They won't build up code relying on SOAP and then be disappointed when new features don't get added or bugs don't get fixed. No false hope and no bullshit: REST is the future.

When

Of course, we know that there is a lot of existing code out there so we're not going to take out SOAP behind the woodshed and shoot it immediately.

Icon

SOAP and XML-RPC will be removed in JIRA 7.0

SOAP and XML-RPC will continue to work without change during the JIRA 6.x lifecycle, however we won't be spending any more effort on bugfixing or feature requests. When JIRA 7.0 is released the code will be removed from JIRA and they will become unsupported by Atlassian.

What

  • The remote APIs provided by the rpc-jira-plugin. The full list can be found here: http://docs.atlassian.com/rpc-jira-plugin/latest/. The JiraSoapService and JiraXmlRpcService are the most commonly used interfaces from the deprecated plugin.
  • The rpc-soap and rpc-xmlrpc plugin module descriptors. These module descriptors can be used by plugins to provide custom SOAP and XML-RPC endpoints. If you want to extend JIRA with custom remote APIs you should use the REST Plugin Module Type.

Feature Parity

Right now the JIRA REST API has pretty good coverage of the SOAP API but it isn't 100% complete. Atlassian is absolutely committed to making every feature of the SOAP API available in the REST API. Making that happen is a precondition of removing the SOAP and XML-RPC APIs from JIRA. We will be working toward that goal during the 6.x and 7.0 development cycles.

  • No labels

6 Comments

  1. Anonymous

    Will this be including user creation/modification and so on . ?

     

    will there also be ability to test user if a password is up to date or not

    Currently they way i do it is call login of soap if the login is a success i assume the password is correct.

    -Thanks

    P.S.

    Only reason i currently cant change to REST is that i cant create /modify and so on users (last time i checked, mat have changed with 6.x i have not checked yet)

  2. You do know there is a REST API that replicates all the SOAP API right? I guess you want a SOAP API that mimics the REST API. Having used both extensively I go for the REST API now. Long term SOAP will likely go the way of CORBA

    1. Anonymous

      You're wrong pal. It doesn't replicate all the SOAP methods. I wish it did though. It is a huge pain convert javascript to XML just to parse the legacy SOAP. I will be happy that morning when I find that I can create an user, update a project and such... using JSON instead of XML.

  3. Anonymous

    I understand the deprecation, but removing the code altogether is disappointing. One of our intranet websites provides a front-end to JIRA for our internal clients; it's been running for years and we've almost never had to change the back-end since its deployment. With this announcement, we now have to spend the time and money required to migrate the code, since IT always upgrades to the latest JIRA. We didn't need any bug fixes or features; we would've just liked the SOAP API to be left as it is.

  4. Anonymous

    You don't need any bugfixes... now.  "Though a program be but three lines long, someday it will have to be maintained."  – Tao of Programming.  Choosing to leave the code alone would not only leave it open to potential security issues down the road, but would also mean that it the code "inside," as it evolves, would have to have static cruft kept around for the explicit purpose of maintaining the stale interface.  The bottom line is that you simply can't just leave code be, especially in an agile environment where refactoring and testing play key roles.  So, yes, it's a drag, but if everyone maintained stale API interfaces forever, what a nightmare that would be.

  5. Anonymous

    What is wrong with this industry????