0

I know this question has been answered several times, but I am still not sure that providing GET with long list of non-structured query parameters or POST to get data is right approach.

I have provided the endpoint:

GET​ /businessrelationships​/{brGlobalKey}

Which returns one resource/object. I would like to provide GET endpoint (as this is safe method) to get predefined list of objects. I was thinking to firstly use POST to create new resource, Lists:

POST ​/businessrelationships​/{brGlobalKey}/lists

with Body : {
  "brGlobalKeys": [
    1234,
    212354,
    3748
  ]
}

The POST will be idempotent and will return listID, for example 123xyz. I would then provide GET to retrieve list with multiple objects:

GET ​/businessrelationships​/{brGlobalKey}/lists/123xyz

Please let me know is this correct method? I know that using 2 instead of 1 call will affect performances, but it is up to the consumer to decide if they want to GET single resource several times or to use list.

Thanks

Prateek Dewan
  • 1,587
  • 3
  • 16
  • 29
Nenad Mijatovic
  • 3
  • 1

1 Answers1

0

I would not recommend to create a separate resource called list. And I think even if you wanted to have a separate resource, it does not make sense as a sub resource of businessRelationship.

If the list of the brGlobalIKeys filter is not too extensive (your example suggests that common API use cases need a handful of keys) I would recommend to use a query string parameter for that taking a comma-separated list of keys and return a filtered array of business relationships. This removes complexity from your service (you don't need to manage the lists of keys) and the client is quite flexible without making additional calls to preconfigure/change the list resource.

Example: https://base.com/businessRelationships?filteredKeys=123,234,345

Philipp
  • 470
  • 2
  • 10
  • Thanks Philip. Agree, it is definitely incorrect to have lists as subresource of businessRelationships/{brGlobalKey}. For the longer list (for example batch of 100 objects) would you recommend POST? – Nenad Mijatovic May 23 '20 at 16:11
  • I am not sure. I think I would try to find another solution. Some ideas: Option 1: requesting resource by resource: Option 2: requesting a list of resources by a key query string as suggested above and add a paging so the client can load like 10 keys per call; Option 3: find another useful filter as query string parameter (guiding questions: how does the client compose the brGlobalKeys? What are the criteria?). But I totally agree, that developer experience and intuitiveness are very important and if you only reach that with a separate resource, you can do so. – Philipp May 24 '20 at 07:42