exercism / problem-specifications

Shared metadata for exercism exercises.
MIT License
320 stars 539 forks source link

rest-api: remove requirement of request data beeing passed in as string #1821

Open NobbZ opened 2 years ago

NobbZ commented 2 years ago

The exercise rest-api has a comment in it that asks to pass in the test data as string, such that an implementation of the solution has to parse and validate on their own.

https://github.com/exercism/problem-specifications/blob/d4d9791b77028b1d9c337202885fb1bfca0a7d86/exercises/rest-api/canonical-data.json#L7-L9

Though according to https://github.com/exercism/elixir/pull/831#issuecomment-880089644, there are only a handful of implementations, of which most just delegate the parsing to a library or stdlib while one seems to use native datastructures, this contradicts to "parsing [...] text payloads is an integral part of implementing a REST API".

On top of that, most modern frameworks that are specialised on building APIs (or added it as more than an afterthought) do already preparse the payload and convert it into a more appropriate data structure.

I agree though, that it is important to validate that comes in. Though parsing a JSON-string into a native structure didn't yet validate the data, it only confirmed that the JSON was syntactically correct.

So an additional step of validating is still required, this step has to be done despite the fact if we pass in a string or a native data structure. This step would check if the given payload actually makes any sense in the current "route".

Additionally the exercise does not talk about how the result should be presented. Though I skimmed current implementations, and Java, F#, C# are expecting strings, which might cause valid solutions to fail, as {"foo": 1, "bar": 2} and {"bar": 2, "foo": 1} and {"bar":2,"foo":1} even are the same 3 JSON objects, though a string based test would only accept one of them, as all three test implementations test for string equality, rather than parsing the response and comparing with native datastructures where the whitespace and keyorder doesn't matter anymore.

Last but not least, not all languages provide JSON parsing capabilities in their stdlib, so students had to implement it themselves or tracks hat to pre-pick a JSON library. Using external libraries can be problematic for some tracks testrunners as not all languages (easily) support pre downloading them.

Conclusion: The current requirement does not add much value but instead adds steps that wouldn't usually be necessary in a "real world" scenario. At the same time it forces the implementation to use a certain canonicalized serialisation form, students who understand JSON, might be asking why only one of the three examples above is considered a passing test.

Therefore my suggestion is, to remove the linked comment and allow for native data structures beeing used as request payload and response.

glennj commented 2 years ago

In the Tcl implementation, I did ignore the string marshalling aspect, and used native dictionaries for the input and output data type.

ErikSchierboom commented 2 years ago

I'm totally fine with removing the comment or modifying it to indicate it as an option.