CODEWITHSUNDEEP
apirestsearchgetapi-design
Édouard Lopez
Édouard Lopez

Reputation: 43401

How to design resource with search method on various fields?

I'm in the process of designing a REST API for a dictionary-like service. Our goal is to support multiple language, but I will take the example of Chinese (iso code: cmn).

I consider my dictionaries to be resources, so for instance I get:

For each language I want to allow fuzzy search in the following field :

Current status

Currently my API is like this:

/api/
    ├── dicts/
    │   ├── cmn/
    │   │   ├── any/{text}
    │   │   ├── ort/{text}   # Simplified
    │   │   ├── ortx1/{text} # Traditional
    │   │   ├── pho/{text}   # Pinyin
    │   │   ├── def/{text}
    │   ├── jpn/
    │   │   ├── any/{text}
    │   │   ├── ort/{text}   # Kanji
    │   │   ├── ortx1/{text} # Hirgana/Katakana
    │   │   ├── pho/{text}   # romaji
    └───└───└── def/{text}

Should I keep my current api layout or switch to another one ?

  1. …/cmn/{field}/{text} current ;
  2. …/cmn/{text}/{field} ;
  3. …/cmn/{text}?{field} use query string parameter to modulate my searches.
  4. …/search/{lang}/{field}/{text} consider search as resource ;

Upvotes: 0

Views: 43

Answers (1)

Ayush Chaudhary
Ayush Chaudhary

Reputation: 716

In my view, the field parameter (ort, ortx1, etc) does not actually qualify as an independent resource. Also, if you see, these fields are common and repeat under each cmn subtree.

A more intuitive approach seems the 3rd one, since the field is merely a restriction in your search. This also allows for a more easier way to allow a default search mode, which would be counter-intuitive and ambiguous to allow if you used field as a resource.

The 2nd approach also faces the issue of allowing for a default search mode and field is clearly not a sub-resource for text.

The 4th approach that you mention looks reasonable if you remove {field} as a resource and add it as a query parameter instead.

Upvotes: 1

Related Questions