0

I noticed that there are couple of ways one can use to get a resource using rest API. I am currently trying to find a valid pros/cons on each of these technique in order to adopt them at the larger scale.

What would be the main differences between these requests? Why would I add id into the path, and not into querystring or request body? Does it have to do with caching or only with resource centered conventions?

[HttpGet]
http://doamin.com/resources/{id}/?filter1=a,filter2=b,
or
http://doamin.com/resources/?filter1=a,filter2=b,id=500

instead of

[HttpPost]
http://doamin.com/resources

Body
{
id: 100,
filter1: "a",
filter2: "b"
}

or

[HttpPost]
    http://doamin.com/resources/{id}

    Body
    {
    filter1: "a",
    filter2: "b"
    }

I find it much more easier to develop endpoints using Post, but I would really like to consider possible issues a developer who will consume these endpoints would actually have.

2

What would be the main differences between these requests?

The most significant difference is the semantics of the method. GET is safe, which means that the resource can be pre-fetched, and we can repeat the request, without concern, as many times as are necessary to receive a response across an unreliable message transport.

POST is neither safe nor idempotent, so we have to be a lot more careful about reacting to "lost" messages.

Why would I add id into the path, and not into querystring or request body? Does it have to do with caching or only with resource centered conventions?

Purely convention, specifically that of RFC 3986,

The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any).

This is convenient in the case of relative references; where we which to have one representation link to a "neighbor" without needing to specify the full identifier.

I find it much more easier to develop endpoints using Post, but I would really like to consider possible issues a developer who will consume these endpoints would actually have.

The world wide web is the reference application for REST. It's going to be your most useful guide in anticipating issues that your API have. In other words - when in doubt, ask yourself what a website does.

0

If you're trying to follow a RESTful API style, it's preferred to have the ID within the URL path (as opposed to the querystring or body params). This makes it so the base URL itself (e.g., the host and path) can fully represent a specific entity.

This also plays into some expected RESTful call structures:

GET me.com/Users/154    (get this user)
GET me.com/Users        (get all users)
POST me.com/Users/154   (post (or PUT) this user)
DELETE me.com/Users/154 (delete this user)
DELETE me.com/Users     (delete all users)

When using a RESTful API, people will generally expect the above conventions.

(granted, you didn't ask about REST specifically, but that's where things tend to fall these days)

  • I am aware of standards, but it seems that these standards dont really follow real life development issues. So I added couple of questions about possible alternatives, and would really love to see some argumented thoughts about it. – John Jun 26 '17 at 10:34
  • Myself, I haven't run into any significant issues with the style I provided, yet at the same time I have no particular issues with the post-body-content style you provided. The latter is a bit harder to read when debugging perhaps, but in the broad scheme of things, likely just another way to skin the cat. With that said, given a couple possible choices where one is becoming or has become a general convention, I'd opt for the one that's a general convention. – jleach Jun 26 '17 at 10:37
  • How about mixing POST with me.com/Users/154 for resource retrieval? I added it to my original question. – John Jun 26 '17 at 10:45
  • Why would you want to use POST for retrieving data? I mean it's possible to do so, but it certainly goes against the grain. The very name of the method belies its use... GET to get something, POST to push something, DELETE to delete something. I mean, you could get items by submitting a DELETE request and you could delete items with a GET request, but why would you? It'd be crazy. Nevermind that it's such a conventional standard that many programming frameworks will infer this behavior automatically. I just don't see a good argument for using POST to get something... – jleach Jun 26 '17 at 11:24
  • how would you structure a GET request if your parameter is a complex object or a multi-array list or it exceeds the max length of an url? – John Jun 26 '17 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.