search

ndmitchell / hoogle

Haskell API search engine
http://hoogle.haskell.org/
Other
738 stars 134 forks source link

use null to indicate failure in JSON API #348

Open poscat0x04 opened 4 years ago

poscat0x04 commented 4 years ago

right now the JSON API uses empty object to indicate failure https://github.com/ndmitchell/hoogle/blob/f9ca6a1669961386f4293be9edd7267136602d59/src/Input/Item.hs#L136-L150 https://github.com/ndmitchell/hoogle/blob/f9ca6a1669961386f4293be9edd7267136602d59/src/Input/Item.hs#L123-L134 I think it would be desirable to use null or to omit that field entirely. The proposed change can be easily implemented with genericParseJSON.

ndmitchell commented 4 years ago

The Hoogle JSON API isn't versioned, which is a shame, as it means this change will be potentially breaking. I agree that either omitting or using Null would be better, but is it better given where we are now? CC @GCrispino for this thoughts.

GCrispino commented 4 years ago

I agree with @ndmitchell, breaking stuff would be undesirable. I believe this could be changed in a future version of Hoogle, that could add versioned endpoints as well (and maybe keep the current version in the same endpoint). How did you deal with breaking changes in the past?

ndmitchell commented 4 years ago

I tend to have been fairly relaxed about breaking changes - avoid where can, accept where I can't. However, I certainly haven't done any breaking changes like {} to null or similar - the payoff isn't high enough. There's no API endpoint versioning, and because of the resources available to the project, I don't expect to introduce any - either the API is similar enough that I wouldn't bother breaking it, or different enough that I'm not going to invest the energy in two incompatible paths.

GCrispino commented 4 years ago

I see your point. So I believe that there's nothing to be done here.