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.

Eric Davis wrote:

The Redmine controllers are pretty fat though so I'd see a lot of refactoring needed to get a good API interface.

ACK. What's your option on this: http://e-haitham.blogspot.com/2008/06/restful-rails-paramparsers-and-xml.html
About authentication: I think OAuth looks like a good solution...

So, I've forked Redmine from Eric on GitHub and have begun to work on a RESTful branch: http://github.com/mknittig/redmine/tree/restful
It's still a bit buggy, but I'm making good progress...

I did some work on Redmine’s URL scheme that would help this. I made the URLs adhere to Rails’ (new) conventions as closely as possible (e.g. /project/ecookbook/{wiki}issues|activity} etc.

See Issue #1901

(I can’t seem to add that issue as proper “related issue”. How come?)

Gerrit Kaiser wrote:

I did some work on Redmine’s URL scheme that would help this. I made the URLs adhere to Rails’ (new) conventions as closely as possible (e.g. /project/ecookbook/{wiki}issues|activity} etc.

See Issue #1901

Looks like a good start, but I think using resources instead of connect is a better solution. I might use some of your tests if you don't mind...

You’re welcome to grab whatever you like from the patch! But let’s think about it:

Sure using map.resources would greatly clean up the routes.rb file, but there would be no other gain than that.

On the other hand, using map.resources requires a complete refactoring of all of the controllers. Redmine doesn’t use named routes internally, relying on url_for params hashes everywhere instead. So using map.resources right away would also require you to check and possibly change all links and forms on the site, a daunting task especially considering Redmine’s spotty view test coverage.

Using equivalent conventional routes where appropriate like in my patch would allow you to create an external interface that is exactly like it should be. Then introducing named routes and using them everywhere, then refactoring the controllers (one by one) to follow Rails’s action conventions and finally switching to map.resources calls to generate the routes seems to me like a more viable migration path, especially considering the significant size of Redmine’s codebase.

Gerrit Kaiser wrote:

You’re welcome to grab whatever you like from the patch! But let’s think about it:

Sure using map.resources would greatly clean up the routes.rb file, but there would be no other gain than that.

You can use the path and url helpers that resources generates...

On the other hand, using map.resources requires a complete refactoring of all of the controllers. Redmine doesn’t use named routes internally, relying on url_for params hashes everywhere instead. So using map.resources right away would also require you to check and possibly change all links and forms on the site, a daunting task especially considering Redmine’s spotty view test coverage.

Good point...

Using equivalent conventional routes where appropriate like in my patch would allow you to create an external interface that is exactly like it should be. Then introducing named routes and using them everywhere, then refactoring the controllers (one by one) to follow Rails’s action conventions and finally switching to map.resources calls to generate the routes seems to me like a more viable migration path, especially considering the significant size of Redmine’s codebase.

Sound's like a good plan to me...

Markus Knittig wrote:

So, I've forked Redmine from Eric on GitHub and have begun to work on a RESTful branch: http://github.com/mknittig/redmine/tree/restful It's still a bit buggy, but I'm making good progress...

Once you get it to good working state, send me a pull request and I'll see about merging it into core (or as a branch of core). With such a large change, I'd like to make sure there is a lot of test coverage.

Markus Knittig wrote:

• REST doesn't like cookies. Some kind of token authentication would be good. Maybe extend the RSS key authentication?

Rather than token auth, why not just use HTTP BASIC auth? Rails 2.0 even has it baked in.

Eric Davis wrote:

Once you get it to good working state, send me a pull request and I'll see about merging it into core (or as a branch of core). With such a large change, I'd like to make sure there is a lot of test coverage.

I'm nearly ready with the principle work. Only two functional test fail ("ArgumentError: tried to create Proc object without a block") and I've no idea why, because they seem to work manually. Also the refactored controller code might sometimes be a bit hackish...
A branch would be fine. It should be merged when 0.8 is done.

Brian Palmer wrote:

Rather than token auth, why not just use HTTP BASIC auth? Rails 2.0 even has it baked in.

Yeah, that might be the simplest solution.

Markus Knittig wrote:

I'm nearly ready with the principle work. Only two functional test fail ("ArgumentError: tried to create Proc object without a block") and I've no idea why, because they seem to work manually. Also the refactored controller code might sometimes be a bit hackish... A branch would be fine. It should be merged when 0.8 is done.

Great, I'm following you on GitHub so let me know once it's ready for some more stressful testing.

Jean-Philippe, how close are we to 0.8? If we still have a lot of time, it might be good to pull in the REST code into trunk and let it stabilize there. If 0.8 is coming up soon, it might be best to keep the REST out until post-release.

So, finally all test pass, but there is still some refactoring to do. BTW: I've not refactored the wiki and the repository controllers and routes yet, because there routing is a bit complicated.
I'm playing around with Selenium for better test coverage (the current test methods don't really cover errors in views). Would it be OK to add the Selenium Rails Plugins to Redmine?
I've also started a new branch restful-ext where I add XML output to Redmine (plus HTTP Basic Authentication for REST Clients).

The work you are doing here Markus is really interesting, thanks and keep it up! Your progress is just inspiring, funny how you at 2008-06-29 posted that you were a Ruby newbie, well now where are we? ;-)

+1

I just commited support for REST urls in r2317. This is the first step towards an actual REST interface.

Just updated, looks great!

Seeing as this issue has been around for such a long time with very little progress, I'm going to take it and see what I can do about it. I'm not promising it will be complete, just that it will be worked on. If anyone wants to help or send me patches I'd love the help. I'll be checking the patches here and the commits on GitHub.

And if you don't see REST, you now have a target someone to ask about it.

Eric Davis wrote:

Seeing as this issue has been around for such a long time with very little progress, I'm going to take it and see what I can do about it. I'm not promising it will be complete, just that it will be worked on. If anyone wants to help or send me patches I'd love the help. I'll be checking the patches here and the commits on GitHub.

Cool, I'll revisit my Redmine RESTful branch this weekend. IMO the main problem is the ugly controller refactoring. A Ruby/Rails Pro like you can probably do a much better job...

I would like to use this Rest API to use Redmine's Tickets methods through webservice to make a link between

How it works ?

Has this work been merged with the main Trunk ?

Thank you for your work.

Yohann

+1 for integrating it into the trunk

+1

and another +1 for a good documentation (or at least wiki page with all mapped URLs)

+1 to know about the status of Redmine APIs. lot of integration stuff could be done with this API in a cleaner way. Can you merge somehow in trunk, even if not 100% complete (but not giving errors, obviously).

TIA!

+1
right now it's hard to write connectors (thinking about IntelliJ and NetBeans).