Jump to content


Click here to lend your support to: Traq and make a donation at pledgie.com !
Photo

REST API


  • Please log in to reply
3 replies to this topic

#1 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 25 February 2012 - 03:23 PM

So I was thinking about a REST API for Traq so let's make a list of what methods should the API have.

Public API
  • Users
    • Get a single user
  • Tickets
    • List based on filters
    • Get a single ticket
  • Projects
    • List all
    • Get a single project
  • Milestones/Components
    • List all
    • Get a single one
  • Timeline
    • Get for specific project
    • Get global timeline
  • Wiki
    • List pages for a project
    • Get single page
    • Get page history
  • Repositories
    • List for a project
    • Get single one

Public API:
/index.json (List all projects)
/[:project].json
/[:project]/roadmap.json
/[:project]/milestone/[:milestone].json
/[:project]/tickets.json
/[:project]/tickets/[:ticket].json
/[:project]/timeline.json
/[:project]/wiki.json (default page)
/[:project]/_pages.json (List wiki pages and specify default one)
/[:project]/wiki/[:page].json

Non public API is public API + this:
  • Users
    • List all
    • Register a user
    • Edit user info
    • Delete a user
  • Tickets
    • Create a ticket
    • Edit a ticket
    • Delete a ticket
  • Projects
    • Create a project
    • Edit project info
    • Delete a project
  • Milestones/Components
    • Create
    • Edit
    • Delete
  • Groups
    • Get all
    • Get single
    • Create
    • Edit
    • Delete
  • Wiki
    • Edit page
    • Delete page

This is an API for admins because it allows to delete and edit stuff, there also should be another API for the users, the other API should have OAuth based authorization IMO.
Traq, yo!

#2 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 25 February 2012 - 03:36 PM

You've given me an idea.

Instead of creating all the API related stuff in their own controllers, why not use the controllers already there, except instead of rendering the HTML views, render a JSON related view, similar to how the overlays work.

I'll have a play around with that idea soon.

#3 Jack

Jack

    Project Founder

  • Administrators
  • 673 posts
  • LocationAustralia

Posted 25 February 2012 - 04:15 PM

How I would like the API to work is like so.

Each project gets its own private key, and because this is an API for admins and project managers there really isn't a need for user keys.

Still trying to decide if the API should use the current controllers or have it's own set. Using the current controllers would help not repeat a bunch of stuff, basically keeping things "DRY" (Don't Repeat Yourself).

Passing the private key and data should be passed via HTTP POST only, there should also be an option to restrict the API to HTTPS.

#4 arturo182

arturo182

    Advanced Member

  • Contributor
  • PipPipPip
  • 151 posts

Posted 25 February 2012 - 05:41 PM

We talked a little with Jack on IRC (join the conversation!) and we came to this conclusion:

Every user has his own api_key since it's easier to revoke API access for a specific user this way.

There will be public and non public API, the public API will allow access to get information about projects/milestones/users etc. but no updating or deleting, that's what the non public API is for.

The non public API will be accessible via POST request and will require the user to provide api_key via request body or HTTP header.

The API urls will be the same as for normal access but with format extensions appended, for example to get tickets for project "test" in json format: http://traq.example....st/tickets.json

JSON and RSS are a must-have, maybe XML.

API will use the controllers that are already in place with alternative layout.

I edited the first post to reflect these changes.

Did I miss something Jack?
Traq, yo!


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users