Experimenting with HTTP services – UrlEcho and UrlReq

Interesting, especially the reasoning behind them:

UrlEcho permits the requestor to completely define the response it wants to receive, thus giving it the ability to “host” static HTTP resources within URLs themselves. Why is this cool/useful? #
 
 
 
 
 
 
 

• You don’t need a Web server to host a simple resource — you just construct a URL and you’re set to go.
• Since resources are cheap to create and throw away, you can create as many URLs as you want, when you want them.
• This is especially useful for testing — you don’t want to configure many server-side resources to return hard-coded responses in order to test correct handling of that response. For example, imagine you need many simple iframes to test a JavaScript library, and you don’t want to modify the server hosting the iframes each time you add or change tests. Since you already know what the responses will be, why not define them in the requests and have a simpler testing process? It makes tests easier to maintain no need to modify the server and understand due to response visibility in the tests.

UrlEcho [ed: UrlReq] lets the requestor to wrap any HTTP request any method, with headers and body into a simple GET request with only an URL defined. Why is this cool/useful? #

• You can make any HTTP request in situations where only a simple GET is possible, or where you can only define just the URL. For example, most systems that provide Web hook callbacks only let you define the callback URL only not the method, headers or body structure.

[ via: Experimenting with HTTP services – UrlEcho and UrlReq. ]