#250 ✓resolved

WebAPI to update project resources file

Reported by Alex-SF | April 7th, 2011 @ 09:46 AM | in Rundeck 1.3 (closed)

Create an endpoint that will invoke the function to update node resources, presently done via the GUI.

Comments and changes to this ticket

  • Greg Schueler

    Greg Schueler April 21st, 2011 @ 03:18 PM

    • Milestone order changed from “18” to “0”

    possible endpoint URLs:




    any preferences?

    I'd lean towards the latter instead of parameterized /resources

  • Deleted User

    Deleted User April 21st, 2011 @ 09:13 PM

    How about:

    POST /api/1/project/name/resources


    application/yaml (the yaml content type)
    (the actual file)

    (the actual file)

    if the post payload is empty, then it defaults back to the url defined in framework.properties (with a log message...actually a log message either way). If it's yaml or xml, it uses that content as the new resource representation

    The POST should return a 302 Moved with a location to /api/1/project/name/resources which returns the underly resource.


  • Alex-SF
  • Greg Schueler

    Greg Schueler April 22nd, 2011 @ 09:16 AM

    Like the post idea...

    but the response should probably not be a redirect to the same URL, that would create a loop.

    response should likely be 200. The content could be the resources data, but that could be large. it could also just be the API response XML format.

    It also points out that the URL for resource data for a project should be /api/1/project/name/resources, currently the API defines it as /api/1/resources?project=name. We could redefine that or support both (perhaps 302 to the former)

  • Greg Schueler

    Greg Schueler April 22nd, 2011 @ 09:18 AM

    actually the /api/1/resources?project=name is maybe better as the query interface, and /api/1/project/name/resources is the endpoint for update/storage/retrieval

  • Greg Schueler

    Greg Schueler April 22nd, 2011 @ 02:17 PM

    some notes on this:

    POST xml or yaml to "/api/1/project/NAME/resources": The content is parsed as resource data, and if valid replaces the existing resources file for the project in current file format

    POST form data with param providerURL=<url>, then the resources file is updated from the URL

    POST with form data param refresh=true, then the resource file is update from stored provider URL if set

    all these respond with 200 and API XML response data.

    GET returns the same data as /api/1/resources?project=name i.e. the resources data, and format=yaml/xml produces the requested format.

  • Greg Schueler

    Greg Schueler April 22nd, 2011 @ 02:36 PM

    I think the /project/NAME/resources endpoint should not be overloaded so much.

    I would like to split out the two Resource refresh requests, perhaps as /project/NAME/resources/refresh

  • Deleted User

    Deleted User April 22nd, 2011 @ 02:44 PM

    Verbs in urls equals much public giggling and pointing.

    Also the 302 would redirect to a GET, basically returning the results.

  • Greg Schueler

    Greg Schueler April 22nd, 2011 @ 03:33 PM

    Yes you are right, 302 does result in GET in browsers (curl actually has a
    special flag to change this behavior to follow RFC and use original method)

    I still think the response should be 200 with API xml content (explicit
    confirm/fail/error response, consistent with other endpoints), but I can
    make it do 302. It raises the question of what format the resources should
    be returned in. If you POST yaml content, are you expecting yaml back?
    (i.e. redirect to /resources?format=yaml)

    A separate endpoint for simply refreshing the resources via a user URL or
    the pre-configured URL doesn't sound good to you? Our api is not very RESTy,
    but the overloaded endpoint seems decidedly un-resty.

    (Btw, our API must seem hilarious..we already have numerous verbs in the API urls...so does twitter).

  • Deleted User

    Deleted User April 22nd, 2011 @ 03:53 PM

    The 302 is a nice to have. Return the results should be based on the accept header from the client. If they want xml or json, then that's how it's served. The requires content negotiation on the server.

    Returning the results after a post, but why not just return a redirect and let the GET handler do the same thing. The client will do the right thing.

    I realize that the goal is not to be a REST api, hence the WEB API designation, but that doesn't stop people from comparing. Twitter gets heat for their API, but they're twitter.

  • Greg Schueler

    Greg Schueler April 22nd, 2011 @ 04:06 PM

    the 200 would result in the standard response format: http://rundeck.org/docs/RunDeck-Guide.html#response-format

    if the client wants the resources they can GET it afterwards, and be explicit about desired format.

    still unsure about refresh action endpoint

  • Deleted User

    Deleted User April 22nd, 2011 @ 04:10 PM

    -1 on the refresh action endpoint.

  • Greg Schueler

    Greg Schueler April 22nd, 2011 @ 05:00 PM

    separate endpoint corresponds to the single GUI button to do the same thing, so i think it makes sense.

    independent of that tho, another question:

    should the Refresh action allow providerURL of file:// as well as http(s)?

  • Alex-SF

    Alex-SF April 22nd, 2011 @ 05:19 PM

    +1, separate endpoint for refresh

  • Deleted User

    Deleted User April 22nd, 2011 @ 05:21 PM

    Yes...definitely allow both file:/// and http:///. Rundeck doesn't run as a privileged user, but some additional security checks would be nice to have.

    For example, an additional check should be made to prevent rundeck from making requests to some random endpoint. Something like:

    framework.properties.secure_domain.0=https://internal.host.network: (regex or glob here)
    framework.properties.secure_domain.1=file:///var/rundeck/* (regex or glob here)

    the above is nice to have considering the users are authenticated before being able to make the call.


  • Greg Schueler

    Greg Schueler April 22nd, 2011 @ 05:24 PM

    ok, allowing file as well as http(s).

    secure_domain is a good idea: add another issue req?

  • Alex-SF

    Alex-SF April 22nd, 2011 @ 05:41 PM

    +1 for separate ticket for this and refresh endpoint then.

  • Deleted User
  • Deleted User
  • Deleted User
  • Deleted User

    Deleted User April 25th, 2011 @ 10:50 AM

    • State changed from “new” to “resolved”

    (from [bb78c5e944c4ed0499d3ac27f375c39be54e2aa9]) Add /project/name/resources endpoint and /project/name/resources/refresh [#250 state:resolved] https://github.com/dtolabs/rundeck/commit/bb78c5e944c4ed0499d3ac27f...

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

(DEPRECATED) Please use github issues for issue tracking at http://github.com/dtolabs/rundeck/issues

Shared Ticket Bins

People watching this ticket

Referenced by