1

I have API accessible via REST. I want to develop library for it. Now, question is, how heavy should the library be? What is the best practice here?

Should I wrap the whole API in objects and basically write REST-object mapper?

Or should the library handle mostly the calling/getting/parsing/auth/... and just return data in some simple form, std::map, std::vector and other come to mind.

Improve this question
5
  • At first: Good idea to offer this! In general we call it an SDK, an example can be found here: github.com/paypal/PayPal-node-SDK About your question: It depends: Best is to map the use-cases a SDK user will likely want to take. Paypal has a more method-call like way to create a creditcard, payments etcetera. That looks look a good fit and easy to implement. If you app is more data intensive, like showing tables of data, filtering them etc. a mapper to objects might be a better fit. It's not about how you supply it but more about what your users need.
    – Luc Franken
    Commented Aug 9, 2016 at 13:33
  • @LucFranken hm, so if I understand correctly you recommend forgeting (for the moment) I'm working over REST, design good solid api for my purpose and then putting REST back into it as a backend which the api will abstract?
    – graywolf
    Commented Aug 9, 2016 at 14:00
  • 1
    Yes, look on it from the side of the potential developer who is going to work with the SDK: How can you help him best to achieve his target. How you implement it (REST in this case) is not relevant for him. Another developer wants to use the raw REST api so he expects you to have that fully REST compliant and with clear errors etcetera. Look from the consumer of the specific tool you are developing. If you would make an SDK for nodejs and php they won't be the same either right? You would adept so they can use it optimally in their environment.
    – Luc Franken
    Commented Aug 9, 2016 at 14:57
  • In most cases, you don't need a client SDK. It's easy to construct/parse JSON and make requests anyway. A client SDK just adds another layer of complexity. Also, it's a lot of work to maintain it for all the different client languages.
    – paj28
    Commented Aug 10, 2016 at 8:21
  • it's only for one language, but it aggregates data from two or three data sources together, that's why I want some abstraction over it instead of direct json requests... plus the api is not very well documented, so user is not really expected to know how exactly call something
    – graywolf
    Commented Aug 10, 2016 at 13:15

1 Answer 1

Reset to default
2

Now, question is, how heavy should the library be? What is the best practice here?

I guess there is only one thing you can use as a guide. The convenience of the end-user of the library.

If you will design your library as a thin, small layer, returning only "int" and "bool" types (exaggarating of course), your users will require ton of wrappers to make the use of it convenient.

If you will make it heavy, all-they-need-in-one-pack, it will become hard to learn, difficult to extend (in case you were unable to predict one customer's demand), difficult to develop and contribute to.

You choose whatever golden mean you can find. Become your user. Think about use-cases of your product.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.