Structuring a GET/POST request to retrieve data using rest API

Question

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.

Answer 1

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.

Answer 2

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)