4 ms·
> Depending on which URL you request, you'll get different result object back. This sounds awful to me. Why wouldn't it be separate functions? I absolutely wou
by overgard 4y ago
> Depending on which URL you request, you'll get different result object back.
This sounds awful to me. Why wouldn't it be separate functions? I absolutely would not want that at all as an end user, I'd find it confusing and frustrating.
- dfabulich 4y agoBecause in order to have separate functions, I'd have to define separate functions for every function that Apple supports, i.e. I'd have to autogenerate the list from Apple's OpenAPI specification. Furthermore, if Apple introduces a new function, I'd have to release a new version of my library to support it. Today, my library can handle any object Apple's API supports, without upgrading. As it stands, the API works like this. It's fine. const {data: app} = await read('apps/123456') const {data: apps} = await read('apps') const {data: [firstApp]} = await read('apps?limit=1')
- overgard 4y agoSwagger can generate that sort of thing. I guess I don't know what things your library provides so I don't want to bash it, but having a generic read/get that doesn't provide types doesn't seem like a big improvement over just using a general purpose tool like axios or fetch.
- JimDabell 4y agoThe App Store Connect API requires scoped, time-limited tokens to be generated and has specific filtering, pagination, and rate-limiting mechanisms built into every resource. I haven’t looked at this particular library, but I would expect that it’s quite useful beyond simply making the HTTP requests.