whytheplatypus / WeBWorK-API

Proposal for the WeBWorK API
0 stars 4 forks source link

Update to Webwork API #2

Closed pstaabp closed 11 years ago

pstaabp commented 11 years ago

Added objects returned and permissions.  Also, changed POST in the add/remove problem set to PUT.

David, let me know if this is what we want before I add more to the rest of the API? In the returns I have put arrays of objects as [User] or [ProblemSet]. Also, we'll need to nail down the database structure to make sure that this makes sense.

whytheplatypus commented 11 years ago

I think we want something more like what github has in its docs.. here's there response for getting stared gists

[
  {
    "url": "https://api.github.com/gists/6148369e0334fe4ccc4b",
    "id": "1",
    "description": "description of gist",
    "public": true,
    "user": {
      "login": "octocat",
      "id": 1,
      "avatar_url": "https://github.com/images/error/octocat_happy.gif",
      "gravatar_id": "somehexcode",
      "url": "https://api.github.com/users/octocat"
    },
    "files": {
      "ring.erl": {
        "size": 932,
        "filename": "ring.erl",
        "raw_url": "https://gist.github.com/raw/365370/8c4d2d43d178df44f4c03a7f2ac0ff512853564e/ring.erl"
      }
    },
    "comments": 0,
    "comments_url": "https://api.github.com/gists/fd7210d327175fbe2ead/comments/",
    "html_url": "https://gist.github.com/1",
    "git_pull_url": "git://gist.github.com/1.git",
    "git_push_url": "git@gist.github.com:1.git",
    "created_at": "2010-04-14T02:15:15Z"
  }
]

I think we want something similar where get users response is

[
  {
    name: "david gage",
    .... more info?
  }
]

and a get single user would be the same without the array [ ]

so basically just fill out what User means in [User]

pstaabp commented 11 years ago

Also, doesn't knowing all the details limit our ability to adapt in the future? That is, if we want to change the database to add a new field to an object that we obviously need to change our API. I was hoping that we have the flexibility if we moved forward to adapt the API.

Example: We write a get users API with existing fields for a user. Then we want to add a field (say hair_color) and the new API will also return that. If anything that we write to use the API is written correctly, it will ignore fields it doesn't expect and a PUT user would fill in hair_color with a default value.

whytheplatypus commented 11 years ago

The PUT change sounds good. I think we want the basics in the API.. and yeah I'm working under the assumption that if extra info is returned it's either being used or wont break anything.