I'm implementing a new REST API. In this API I typically POST to collections to create resources. For one of my resources, the ID is known before it is created. Does it make more sense to post to the collection with the ID in the body or to post to the instance (as yet non-existent) with the ID in the URL?
I'd say keep the existing endpoint and just add the ID in the body when POSTing to that collection, there's no point in adding a new separate route for what's basically the same thing.
From another thread: https://stackoverflow.com/a/18474955/1851581
You can also use PUT with the ID in the URL, instead of POST.
PUT is used for upserting, covering mainly updates but also the creation of the resource if it doesn't exist.
I ended up posting to the collection with the ID in the body. That keeps with the pattern elsewhere in my API. The only difference here is that the ID is supplied in the body.
Related
I read that the route for getting a nested resource in REST should look like this
/articles/:articleId/comments
The owner (:articleId) of the child resource will be visible.
But what if you have an owner that you don't want the client to know about?
For example, let's say I have an app where users have anonymous posts. I wouldn't want other users to see the client fetching the post by /users/123/post/321 because users could identify who wrote the post from the id and it wouldn't be anonymous.
Is the id necessary? Is it ok to instead do /users/posts/321 if all posts have a unique id?
There are no actual requirements for the URL format. It can be whatever you'd like it to be.
If it were me, I would use simply /posts/321 and leave users out of it, since a particular user isn't specified in your URL at all. I think that's the clearest way to handle it in your case.
I create rest api and I have a POST which has many comments. What is the better url to get post comments
//Get all comments of a post
GET /posts/{postId}/comments
or
GET /comments/{postId}
//Create new comment
POST /posts/{postId}/comments
or
POST /comments/{postId}
A POST has many CATERORY and a CATEGORY can belong to many POST
How I can create a post with ,for example, 3 categories. And how I can connect a specific existing post to a specific existing category
What is the better url to get post comments
REST doesn't care about your spelling conventions for URI -- that's part of the point. So you should use whatever spellings are consistent with your local conventions.
Depending on your API and representations, it may be useful to think about relative references in your hierarchy. For instance, if your base URI is /posts/{postId}/abstract, then the relative reference ../comments can be resolved to /posts/{postId}/comments; but there is no analogous trick to get you from /abstracts/{postId} to /comments/{postId}.
How I can create a post with ,for example, 3 categories
how I can connect a specific existing post to a specific existing category
How would you do it with a web site? Having done that, how would you make the web site machine readable?
I need to design an operation “duplicate” for "articles".
My thought was: a POST on apibaseurl/articles/{id}/duplicates and returning a 200 OK with the URI of the created duplicate, which's URI however will conform to the template apibaseurl/articles/{id}.
When issuing a GET to apibaseurl/articles/{id}/duplicates however, there will not necessarily be a list of duplicates (meaning: the server will not keep track of all duplicates created for an article - the "duplicate" relationship is ignored by the server outside the scope of the request)
Questions:
is my suggested solution OK?
does it not violate any RESTful principle by having the URI of the created object point to a location not under the resource under which it was posted?
would I have to provide a client with the possibility to list all duplicates for an article?
is my suggested solution OK?
It looks fine to me.
does it not violate any RESTful principle by having the URI of the created object point to a location not under the resource under which it was posted?
No, that is not necessary. You POST to a collection resource but this does not force you to return a Location header pointing inside this collection.
would I have to provide a client with the possibility to list all duplicates for an article?
If you have a use case for this, you could provide it. But if there is no business interest in listing the articles created as duplicates of an existing article, you don't have to.
Go ahead :)
I am trying to build a little web application with the MEAN stack (MongoDB, ExpressJS, AngularJS and NodeJS).
My question is very simple. If you take the example of a blog, it will contains blog posts, that you could list at this url:
GET /api/posts
You could also get the comments for that posts:
GET /api/posts/:postId/comments
and get a single comment:
GET /api/posts/:postId/comments/:commentId
The relation between post and comment is really obvious here, but does it still makes it mandatory to have it this way? or could I just perform my CRUD operations through /api/comments? In the end, a comment object in mongodb will always have a postId attribute anyway which will reference the post that it is related to... Moreover, the API will not be exposed and is strictly meant to be used by the application.
does it still makes it mandatory to have it this way?
No. This is not mandatory at all.
or could I just perform my CRUD operations through /api/comments?
Yes. This will result in cleaner resources URIs (endpoints).
You can also get post-specific comments with:
GET /api/comments?postId={postId}
Further, you could also drop the /api prefix if you are serving only an API at the given host.
When you want to "unlike" a built-in like action on an open graph object, you have to send an HTTP DELETE with the id of the like story itself. But that requires either:
Querying the graph for the ID of the story before deleting it, or
Stashing the ID that's returned when you create the like in the first place.
Neither of these are satisfying solutions. It would be nice to be able to do this all in a single request, preferably with nothing more than the URL of the liked object.
Because this modifies the graph, the Graph API has to be used, right? AFAIK, FQL is still read-only.
Half the battle is figuring out a way to use the Graph API to look up the ID of the like story given the URL of the liked object:
GET http://graph.facebook.com/me/og.likes?object=http://url.to/your/object&fields=id
Once you have that, you can name it in a batch query, then refer to it from the DELETE request using JSONPath (details here under "Specifying dependencies between operations in the request"):
POST http://graph.facebook.com/
batch=[
{"method":"GET", "name":"like_id", "relative_url":"me/og.likes?object=http://url.to/your/object&fields=id"},
{"method":"DELETE", "relative_url":"?id={result=like_id:$.data[0].id}"}
]