The HTTP Query/Response Event is the most convenient way to create a RESTful web service in MDLink. It is a different kind of event, because it has two parts - a "query event" part and a "response task" part. This is to enable other components to be used in building the response. For example, one could use a database SELECT task to get data from a database based on the request, and build the response based on that data:
With a conventional (that is, unidirectional) MDLink event, this would be impossible.
You must connect the query event to it's corresponding response task, either directly or indirectly. Also, you must do some datamapping going into the response task - even if it's just to create an empty response body (as you could do by right-clicking the "body" element on the target side and selecting "Map this target without a source").
You can create the HTTP response however you like, through datamapping and the standard HTTP mechanisms that are reflected in the input schema for the response task - "body", "status code", and "header". Likewise, all of the different parts of a standard HTTP request are reflected in the output schema of the query event (such as "method", "path", and "query".)
An HTTP Query/Response Event listens on a particular port and will fire on all HTTP requests, regardless of the method (GET, POST, etc.), path, or any other aspects of the request. If you would like your solution to ignore certain methods or paths, you can implement a task execution cancel or fail (through a datamapping script or otherwise), so that the response task is not executed for that event firing (that is, transaction).
Generally you should build your solution to ensure a one-to-one relationship between firings (i.e. transactions) of the query event and executions of the response task. If the response task is not executed for a certain transaction, then this is considered an error. It will be logged in MDLink and a "404" error will be returned to the web client. If the response task is executed more than once for a certain transaction, then the first execution will dictate the response sent to the web client, and subsequent executions will be logged as errors and will not be seen by the web client.