3 ms·

RESTful APIs can be a pain when you have to mashup different APIs, though. The amount of calls you end up having to do can be quite a lot. From a backend standp

RESTful APIs can be a pain when you have to mashup different APIs, though. The amount of calls you end up having to do can be quite a lot. From a backend standpoint it's not that bad if you cache, but from a consumer standpoint I have to get a /users/active list, iterate over them, then call a /friends/[id] call for every user. If you add a third list you can easily see how annoying it might be. It's great that your APIs can be so flexible but now your clients are writing completely different code all over... the chances of you breaking something or them having to re-code things every release is a lot greater than updating a getFriendsOfActiveUsers traditional API call. Has anyone else found this to be the case? Are there ways around it? I'd almost want a hybrid or a mash API that I can pass in URLs and have it return a mashup for me.

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.

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.