Our use case for ReadyAPI is REST API Testing. We essentially test student data because we're working for a school domain that can have different ReadyAPI test cases.
We have the positive test scenario where we collect real-time data and they pass through ReadyAPI, then post different data types for students, such as the school students enrolled in, whether students are full-time or part-time, what courses the students took, etc. There are positive scenarios and negative scenarios that we try to create in the system, including some junk data, then we'll see how ReadyAPI will behave.
ReadyAPI being a tool, means that you can also feed it any junk data, and it's going to post that data, but what we'll be looking forward to is the HTTP code generated towards the end of the day, to see whether it's valid or not.
If there are irrelevant data, for example, there's an address field that can accept any characters, that should be fine, but if we have a name that we need to find and we provide some special characters, then ReadyAPI will give an error message similar to this "Hey, it looks like you're using special characters, so that won't work for me."
There are multiple edge cases, but it isn't about the tool. It's about the applications being used, and there may be some loose ends within the applications. Edge case scenarios could come up, such as the positive scenario and the X, Y, and Z scenario, and ReadyAPI helps us and makes it easy for us by allowing us to post the data. It lets us create multiple test cases, for example, if we have fifteen resources for a test case, we can tightly bundle those resources under one test case, then execute the test case, then ReadyAPI will run everything under that particular test case.