I generated an API key for my Rally account. Is there a REST API to retrieve my basic user information, such as name, ObjectID, and ObjectUUID?
Sure, you can just read the /user endpoint and fetch whatever fields you need. This endpoint can both be used to query for multiple users, or if just read without any parameters it will return yourself.
So, to get yourself:
GET https://rally1.rallydev.com/slm/webservice/v2.0/user?fetch=ObjectID
Or to query for users (which you're probably familiar with):
GET https://rally1.rallydev.com/slm/webservice/v2.0/user?fetch=ObjectID&query=(UserName contains "Bob")
Related
I just started to construct REST API refer to this guide.
It's my first time coustructing REST API architecture, so something ambiguous.
POST vs GET
Before learning about REST API, I choose POST when I don't want form-data being exposed(e.g. user's ID, password, phone number).
But in REST API, POST means 'create new resource' if what I learn is right.
If so, what is the proper method for following case :
'check user's ID is duplicate or not', 'find my id or password'
represent specific action
REST API guide says that use noun to represent.
I Usually named function or method by verb+noun combination(e,g, checkId, findPassword).
Then what is proper(or better) way to represent?
GET /user/check-id
GET /user/id/check
GET /user/id/duplicate
Take a look at the RESTful verbs. POST is definitely used to create something, and GET is a query. That being said, you are absolutely right that GET URL Parameters are often logged all over the place, and you should not use them in GET urls if they contain sensitive data.
To check if a user's ID is a duplicate, I'd do a POST with the user's ID, and return a HTTP 409 code if it already exists.
The find password is a different question. In short, don't do it. You should NEVER, EVER, EVER store a user's password in plain-text. Doing so is negligence in today's computing world. Resetting a password should involve creating a password reset request (A POST to a /user/id/reset), which results in a password request being sent via another channel, but never, ever return a password from a GET request.
I need a URI in my REST API to retrieve the current logged in user. Usually I use GET on resource with ID, but the client doesn't know the ID of the user.
I found the following solutions:
By user name
This solution uses the user name instead of the ID of the user.
Example:
Bitbucket REST API: GET /user/{userSlug}
With own resource
This solution has one resource for users and one additional resource for logged in user.
Examples:
JIRA REST API: GET /myself
GitHub REST API: GET /user
Stack Exchange REST API: GET /me
With symbolic link
This solution has a symbolic link for the ID of the user.
Example:
Confluence REST API: GET /user/current
With filter
This solution uses a filter for the user name.
Example:
JIRA REST API: GET /user?username={username}
Which one is most RESTful? What are the pros and cons?
It's up to you. All the approaches are perfectly fine from a REST perspective.
According to Roy Thomas Fielding's dissertation*, any information that can be named can be a resource:
5.2.1.1 Resources and Resource Identifiers
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. [...]
When using /me, /users/me, /users/myself, /users/current and similars, you have a locator for the authenticated user and it will always identify the concept of an authenticated user, regardless of which user is authenticated.
For more flexibility, you also can support /users/{username}.
By the way, a similar situation was addressed in Is using magic (me/self) resource identifiers going against REST principles?
* If you are interested in REST, the chapter 5 of Fielding's dissertation is a must-read.
I think REST URIs should uniquely identify the resource, no matter it' using userId/email/ssn or username, whichever attribute uniquely identify user in your system.
So, resource can be users (plural /users) and to make it singular we have below options,
If client has userId, resource should be something like,
GET - /users/{user-id}
If client doesn't have userId, but has username, then
GET - /users/{username}
So, as long as uri uniquely identifies user, we can use above uri patterns as a REST resource.
If, client doesn't have userId, username or email or any other attribute which uniquely identifies user in your system, then, we can have resource uri something like,
GET- /users/current
OR
GET- /users/me
But, in this case, client needs to have user specific TOKEN or session enabled, so that server can find user from active session or token passed in headers.
Note, we should consider this a last option.
All are equally RESTful. REST is not about URIs, it is about using them RESTfully.
REST is about the client navigating application state. Part of this state may be who is the current user. All URLs can be used to get this part of application state.
Say I have two resources, users and items, for example,
api/users
api/items
I want to store a record of when an user access an item (which items has access each user). What would be the correct way to do this in a REST way.
I could do something like this
POST
api/items/1
{an userId}
instead of GET request and retrieve the item and create the view record. Or using a GET request on api/items/1 and then relying on the client to call another api method to add a view record. But those ways just don't feel right.
Is it a recommended way to do something like this in a REST way?
I'm curious as to why you want an auditing function like storing who viewed the record to be an external REST API call...
I would think the simplest REST API would be to make the access a GET request like https://{url}/api/items/{id}?token={something_from_authentication_call} assuming that you've authenticated the user and provided them a token to use with all calls.
Then, since you're internally maintaining a token-to-user association somewhere, have the backend service either write the auditing data directly to a database, or call some other internal service not exposed to the outside world to create the auditing data.
Don't you use authentication before calling your REST? Usually user authenticates before and when the REST is called you know who is calling.
If you don't have authentication you can use any method of passing user as body parameter or as request header.
how do you handle a user 'liking' a post or object in a RESTful API so that they can only like it once? Do you create a many to many relationship and create an endpoint to check if a user liked the object for each object that you load? This seems very request intensive and I'm wondering if there is a better, established solution?
Assuming that the users must be authenticated to perform the request and the request contain all the details to be properly authenticated, you could consider the following approach:
POST /posts/:postid/likes: Records a like for the user in post with the given id.
GET /posts/:postid/likes: Returns a representation of all likes for the post with the given id.
DELETE /posts/:postid/likes/:userid: Deletes a like for the user in the post with the given id.
I'm doing a GET for customers with a given email address (there will only be one). Before displaying the returned information, I need to authenticate the user, but I can't see a way in the docs that allows providing a password as a parameter to a GET. In fact It only seems to be possible to provide a password when creating (POSTing) or updating (PUTting) a customer. Is it possible to authenticate customers via the API this way?
from what I understand - _authentication is only supported for POST and PUT on customer objects. I believe it is intended to create a customer who can login and stuff like that.
Can you explain your use case and maybe there is a workaround..