11 ms·

This is an issue I'd like see more people talk about in REST API design. There's quite a balance to be struck between the number of calls to be made and the siz

by notJim 15y ago

This is an issue I'd like see more people talk about in REST API design. There's quite a balance to be struck between the number of calls to be made and the size of the data that needs to be download. I designed a REST API that's primarily (well, currently only) used for mobile applications, and it was often hard to decide whether to “denormalize“ the API (fewer API calls required, but more data per call) or provide very general fine-grained resources.

ataggart 15y ago
One need not exclusively describe every sublist as a separate resource. Sorting and filtering can correctly be implemented as query params on the full list resource. Perhaps the shunning of query params (rightfully so when used as verbs) has gone too far.
- smackay 15y ago
  Hear, hear. REST APIs are particularly difficult to implement when you have multiple optional value to query/describe a particular set of resources. The RESTful way encourages an explosion of URLs to try and support the different combinations. Adding new ways to list resources at a later date is also next to impossible. Query parameters simplify the process and the API significantly and still make it easy to describe and use. For me the best approach is to mix the two: make often used, pre-defined queries RESTful then support all the specialised combinations through query parameters.
methodin 15y ago
I know what you mean. I've often shied away from using REST simply because I like to setup the APIs as classes and use the classes directly in my internal code usage. REST breaks that for me, not only because the paradigm is different, but if it was truly REST I'd be making CURL calls to myself to get the data which single-handedly bloats my code by an order of magnitude... It definitely deserves some discussion to find out if there is a way around this problem as blindly going REST can cause some very difficult problems down the road.

by notJim 15y ago

ataggart 15y ago

One need not exclusively describe every sublist as a separate resource. Sorting and filtering can correctly be implemented as query params on the full list resource. Perhaps the shunning of query params (rightfully so when used as verbs) has gone too far.

smackay 15y ago
Hear, hear. REST APIs are particularly difficult to implement when you have multiple optional value to query/describe a particular set of resources. The RESTful way encourages an explosion of URLs to try and support the different combinations. Adding new ways to list resources at a later date is also next to impossible. Query parameters simplify the process and the API significantly and still make it easy to describe and use. For me the best approach is to mix the two: make often used, pre-defined queries RESTful then support all the specialised combinations through query parameters.

methodin 15y ago

I know what you mean. I've often shied away from using REST simply because I like to setup the APIs as classes and use the classes directly in my internal code usage. REST breaks that for me, not only because the paradigm is different, but if it was truly REST I'd be making CURL calls to myself to get the data which single-handedly bloats my code by an order of magnitude... It definitely deserves some discussion to find out if there is a way around this problem as blindly going REST can cause some very difficult problems down the road.