Redmine

No, i don't think it would be too early. Main model objects (projects, issues, ...) are stable enough. Even if they may be extended in the future.
Could you briefly specify what you expect from this API in terms of entry points ? (eg. fecth issues, create an issue, ...)

I think that a minimum requirement should be to have an API that give full access at the issue level. This means access issues (CRUD), all the related models at least in read only mode (issues categories, etc..) and query support. This should be fine for attaching a single project from an external entity and a good starting point to build other features once the API starts being used.

In other post (the one on the svn hooks) we briefly talk about security concerns, but thinking again it could be delayed (i.e. handled by the sysadmin). The only thing to consider is the user/s the service/s will be bound to

I hope to have some time to think about the issue and give a more detailed answer.

Regards

Can I also vote for an API please. I think it would open up a whole world of possibility for an already cool product.
I'm certainly thinking query, create and update issues. For instance I have in mind something that would allow feature items to be created from an RSpec file.

It's only one of the minor points of the original request so i'm afraid i might be slightly off topic, but i have successfully connected Eclipse Mylyn with redmine via the Generic Web Repository Connector.
Even though it provides just a very basic integration with eclipse/mylyn i thought maybe the configuration would interest a couple of people since there is, to my knowledge, no dedicated connector for redmine yet. please contact me if you're interested in the configuration, maybe a wiki howto would be a good idea...

Maximilian, this sounds interesting could you send me wome further details at mnv (at) coolsms.dk

Thanks in advance.

+! for me. A REST API would be a very useful feature.

+1 Would like to build an Redmine-AIR-Client based on the REST API :)

+1 for REST API. Would like to see a SOAP 1.2 compliant interface. See issue #725

+1 for REST API

What about JSON format for usage in AJAX / RIA applications? I think it wouldn't take much more effort to add a JSON output as an supplement to XML and it would integrate nicer and more efficient in JavaScript driven applications.

Seems like this issue has had a lot of feedback and there are a lot of votes for a REST API. Though I would normally also vote for REST, we've been relying on Mantis (http://www.mantisbt.org/) as our gateway issue management solution for years. Though Redmine wants to replace Mantis, we like it too much to use anything else for awhile. We have about 100 projects in Mantis now.

Our business process would be to receive issues into Mantis, evaluate them, then pass the ones to be worked into Redmine. Mantis has a SOAP API. So I guess we'd really like to see a SOAP API, or some other mechanism to pass selected issues to Redmine from Mantis.

Of course this might involve a REST service from Mantis..

+1 for REST API

would really like to see a mylyn connector for eclipse!!

+1 for REST API
a mylyn connector for eclipse should be so nice!

To the user who was able to set up the generic mylyn connector, Any chance of posting details?

I'd love to see a native connector - that seems to be the big thing that trac still has over redmine.

I've just added an Howto on using the Mylyn generic connector: HowTo Mylyn

Thanks for the HowTo. Unfortunately, it doesn't seem to work for me. I haven't found a way to diagnose the problem. I have a bit of a suspicion that the login isn't working because when I try to open the query in a browser it fails. But I don't have enough understanding of the mylyn connector to be sure that I'm interpreting that fact correctly.

Thank you very much for that HowTo, I guess the request for a fully featured Mylyn connector would have to go to the Mylyn development team.

I raise my hand for the REST/SOAP API though, because it would be very useful to integrate redmine into other applications in an consistent way. Propably now you would just access the Redmine Database structure and retrieve the information you need in another application. A consitently defined gateway would be much more useful.

+1 for REST API

ruby ${REDMINE_HOME}/script/runner "Issue.create :tracker_id => 3, :project => Project.find_by_identifier('${PROJECT_NAME}'), :sub
ject => '${SUBJECT}', :description => '${DESCRIPTION}', :author => User.find_by_login('${USER_NAME}'), :start_date => Time.now" 

I would love this feature also but looking at this from a development point of view, it's a huge undertaking. What might be a better way to make progress is to break it into smaller parts. Since it sounds like an issue API is a common request, I created #1214 for the issues API.

I have posted a video on youtube to go along with the HowTo Mylyn

+1 for Mylyn integration here too.

We are using the Generic Web Connector, as per the wiki page (thanks for that) but proper integration would be better.

We evaluated Eventum before deciding on Redmine, and our approach to Mylyn integration was going to be to produce a XML-RPC interface that matched the Trac one (because it is open source) and then try to use the native Trac connector to talk to Eventum. We're not able to attempt this for Redmine because we are a PHP shop, but someone else might want to consider if this is feasible. We figured this approach was possible using our existing skills, whereas writing a native Mylyn connector wasn't.

We would also consider using a REST/SOAP/XML-RPC interface to write an integration between dotProject and Redmine (it currently has integrations for Eventum and Mantis) and between our existing in-house issue tracker and Redmine.

Thanks
Roger

Jean-Philippe Lang wrote:

I've just added an Howto on using the Mylyn generic connector: HowTo Mylyn

Please can you update this page:

Server:                 http://www.company.com/directory -- Replace it with the URL of your Redmine instance
Query pattern:          <td class="subject">.*?<a href="/directory/issues/show/(\d+)">(.+?)</a></td> -- replace /directory as required

Note the /directory in the query pattern, which must match the directory path you access Redmine at.

Thanks
Roger

+1
I'm also very interested in an Mylyn connector. The Generic Web Connector doesn't have enough features for me and the Generic SQL Connector is not flexible enough. I would help to develop one, but before that a API is needed. Unfortunaly I'm a Ruby newbie, but maybe this can help: http://www.xml.com/pub/a/2006/04/19/rest-on-rails.html

Here is another good link: http://www.b-simple.de/download/restful_rails_en.pdf

• REST doesn't like cookies. Some kind of token authentication would be good. Maybe extend the RSS key authentication?
• Rendering single objects like projects are easy. But rendering e.g. issues with journals, timelogs and attachments as XML is tricky.
• Haven't thought about querying custom fields, enumerations, etc.

Someone has already created a basic XML-RPC service for Redmine: http://sourceforge.net/projects/redmin-mylyncon/
I'm looking into that, because I don't think it's possible to get Redmine RESTful without some serious rewrites...

Markus Knittig wrote:

So, I've played a bit with REST and Redmine. It was quite easy to set up even for me as a Ruby newbie. I successfully deleted projects and created a issue with curl. Problems:

• REST doesn't like cookies. Some kind of token authentication would be good. Maybe extend the RSS key authentication?
• Rendering single objects like projects are easy. But rendering e.g. issues with journals, timelogs and attachments as XML is tricky.
• Haven't thought about querying custom fields, enumerations, etc.

Looks like a good start. If I get some time I can try to lend a hand, I have a few years experience with REST and Ruby on Rails. The Redmine controllers are pretty fat though so I'd see a lot of refactoring needed to get a good API interface. I'd image the API would be a good 1.0 feature with maybe a preview release in 0.9.