THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Methods, Resources, and Descriptions
Bold means the resource and method is implemented in the current /api2/ endpoint.
Resource | Method | Description/Payload schema/Response schema | |
|---|---|---|---|
apiapi2/sessionssession | GET,POST | api/sessions/SESSIONID | ,DELETE |
apiapi2/users | GET | ||
apiapi2/user/messages | GET,POST | should support/encourage a stream-based interface | |
apiapi2/user/followees | GET | ||
apiapi2/user/followers | GET,POST | ||
apiapi2/user/followees/USERID | POST,DELETE | or POST api/users/USERID/followees?user=USERID2 | |
api/user/api2/user/tracks | GET,POST | ||
apiapi2/user/tracks/TRACKID | DELETE | ||
apiapi2/user/actions | GET,POST | ||
apiapi2/user/actions/ACTIONID | PUT,DELETE | ||
apiapi2/messages/MESSAGEID | GET,PUT?,DELETE? | ||
api2api/messages | GET,POST | ||
api/tags | GET | Return all of the tags, or user-specific tags (GET api/tags/USERID?) and let the front-end decide what to do with it. | |
api/tags/TAGID | GET | Gets the information about a particular tag | |
api2/conversations/CONVERSATIONID | GET | ||
api2/pools | ... | api/conversations/CONVERSATIONID | GET |
One point to note is that many HTTP clients do not currently support the "PUT" or "DELETE" methods, so these may have to be simulated through POST methods with an extra parameter. I think that because of the close mapping to resource verbs, is worth using these methods in the specification and defining the simulation method for the entire API separately.
...