When developing, I’ve always preferred to get my hands dirty and use a try-and-error approach than to go through lengthy documentation scrolls carefully. I found it easy to open the collection in Postman, check the services and their parameters (what headers were needed, what filters in the URL, the response payload, etc…), and implement the REST API in OutSystems. Later, I started working on POCs where the customer would share a Postman collection.
But for edge cases, when something was missing or not working, Postman was a great complementary tool to better understand the requests, their headers, and payloads.īut as I soon realized, I was only scratching the surface of Postman.īeing the lazy developer I am, I would have only one collection and one service that I would change according to whatever API I was testing. Exploring an Iceberg Called Postmanįor most REST integrations, I was able to implement and test them in the OutSystems IDE.
So I wasn’t surprised when I first discovered that there was a tool to test RESTs.
Rest api tools like postman code#
Tools to manage time, tools to manage tasks, tools to optimize paper, tools to test code, tools to write code - tools, tools, tools! The good news is that there are tools for pretty much everything. So I had to dive into the wonderful world of REST requests.Īs a carpenter needs a hammer and an accountant needs spreadsheets, developers need their tools. Many of these POCs required us to connect to REST APIs, some with custom integrations with third-party services like Facebook or Twilio. Throughout my career, I worked on many proof of concepts (POCs) and projects for many companies. I was getting familiar with front-end and back-end, and soon enough, I was working with REST integrations. I started developing in Java and changed to OutSystems in 2015, where I began developing web applications on a path to become a full-stack developer. I have been a developer for almost a decade (est.
0 kommentar(er)
