For a few weeks now, people have been asking “can I have the restapp you were showing” – well, here it is: https://github.com/waldo1001/waldo.restapp
But that would be not much of a blogpost – would it ;-).
Just an example…
During NAVTechDays, I did 2 sessions:
In both sessions, I talked about the concept of “dependencies”. Yes indeed – in my opinion, “dependencies” is an opportunity that we should embrace .. (just watch the “Development Methodologies” session if you want to know how and why). Now, during the sessions, the RESTApp was actually just an example on how we internally “embrace” the concept.
What does it do?
Well .. not much, really. At least if “making your life a lot easier” is “not much”, that is ;-).
It just “encapsulates” the complexity, the functionality, the responsibility, the “whatevery” that has to do with “REST Calls”.
I mean, did you ever try to use the httpclient-wrappers to do any kind of “decent” webservice call? Did you ever fumble with setting the “content-type”, or any kind of headers? And honestly – did you spend more than 5 minutes to make it work? Well, if all answers to these questions are “yes” .. Then you will appreciate this app ;-).
Or as a picture tells you more than an 1000 words, it turns this code:
I hope you agree that this second way of handling the same call, is a LOT easier:
- Not having to declare all these different http-types, just the RESTHelper codeunit from the RESTApp.
- Not having to care about the order of adding content type or headers or anything like that
- Not caring about error handling.
The current functionality includes the following things:
- A helper codeunit for REST calls
- A helper codeunit for JSON stuff
- Logging of the request and the response message
I could have done that with a simple codeunit, dude
I hear you. “Why an App? Why implementing the complexity of dependencies for such a simple thing?”
Well, it’s not just there to make your coding easier. It’s there to make the whole lifecycle of how you do webservice calls in all your projects easier. Just think about it. You are probably going to do REST calls in many different products and/or implementations. And many of them are different, need more functionality, …
Or – you just might run into a bug on how you do it, and have to update a bunch of other implementations .. .
Or – at some point, you might figure that having a decent logging for all outgoing REST calls would be interesting (and let me tell you that: it IS interesting (and yes, it’s already included in this app))! If you have implemented a RESTApp like this, a simple update gives you this new functionality on ALL your projects. Simply release it to all your customers (long live DevOps!). You can update all you want .. as many times as you want.
Or – at some point, you need to be able to set up “safe” sandboxes, and need to overrule all webservice-calls in a sandbox to not risk “live” calls from a sandbox (guess what – this IS something to think about!)? Just update this app, deploy, done! On ALL your customers.
I can give you lots of scenarios, to be honest.. . But tell me again – how is that codeunit going to help you in any of this? 😉
Just an example
I know, I already had this subtitle :-). But now, it’s more like a disclaimer.
Don’t see this code as being a leading app. It’s meant as an example .. and nothing more. It is not the version we are using internally (which I’m not allowed to share, as I don’t own the code). It doesn’t have “authentication helpers” or anything like that. And it probably doesn’t have all the functions that are necessary to do all kinds of REST calls. Obviously, this is where you can come in :-). May be it’s not a “leading app” now (if that’s an expression at all) .. you can help me make it one ;-). Please feel free to do any kind of pullrequest. Anything that might help the community. Change, restructure, .. whatever!
May be, at some point, it’s mature enough to pullrequest into Microsoft’s System Application ;-). In this current state, in my opinion, it isn’t.
I do have some ideas that I want to include in this. Like making it easier to work with different authentication-types. Or including a way for a test-url, like request-bin, that replaces all calls with this url for you to be able to track the actual request calls that are being generated.
If you have ideas, or remarks, or anything, you can always leave a comment – or use github and use the “issues” section to add ideas (or issues).