Fetching multiple resources using Ids

I have requirement to fetch multiple articles in one response in GET. Is bellow allowed?

api.xycp.com/articles?filter[id]=111&filter[id]=222&filter[id]=333

Am I violating any standard?

Personally I would do

filter[id]=111,222,333

Though depending on the reason for your need to fetch multiple resources by ID, you may consider if the resources should be in some relationship, so that you can just fetch it like a normal relationship.

Hey, your way wouldn’t work to good, because you always override the value from before.
(you would have to send is as array ?filter[id]=1&filter[id]=2&filter[id]=3)

I wouldn’t make that comma-separated list inside a filter.
Either you call the resource-url like:
/articles/1,2,3

or
you can implement an advanced filtering called LHS brackets.

In you example:
/articles?filter[id][in]=1,2,3

Advantage here, beside operator “in” you can implement “startsWith”, “endsWith”, “contains”, gt, gte, lt, lte, xor, etc. what you can think of and what is needed.

In the first case you implement GET /articles/1,2,3
you can do the same with destroying requests DELETE /articles/1,2,3
or even changing lots of objects with request PATCH /articles/1,2,3 { publish: true }

And its a legitime restful pattern (It is NOT specified in jsonapi, but neither that it is NOT allowed)
So in my opinion this is free to you to choose.

The JSONAPI spec specifically doesn’t define the semantics of filter but there is a recommendation that shows an example of the filter[id]=1,2,3 style and the implication that multiple filter occurrences are ANDed together – there’s really not a way to OR filters that I’ve seen examples of other than list membership.

If you are using Python/Django there is this implementation which uses something based on the Django __ (double underscore – remapped to dot) notation, for example: filter[id.in]=1,2,3 or filter[id.lte]=3.

I would avoid that. It isn’t clear what it is. Maybe this is an ID that contains commas? Also, I’m not sure it’s allowed by the spec. It’s definitely very hacky. There are much cleaner solutions to the problem we have here.