Home > Software engineering >  REST API design: param value starts with
REST API design: param value starts with

Time:01-11

I need an REST API endpoint which will return all the records having name starting with ABC. The SQL query would be something like:

SELECT * FROM MyResource WHERE Name LIKE 'ABC%'

But how should I define the query string in the REST endpoint? Using equal sign in the query string would not be appropriate, I think.

{Base URL}/myresource?name=ABC

Sofar I found following specification that can be used as base for the definition of the query: https://datatracker.ietf.org/doc/html/draft-ietf-scim-api-12#section-3.2.2.2

CodePudding user response:

Equals is fine provided you use correct naming. For this request you can define i.e. 'namePrefix' parameter that is self-descriptive.

CodePudding user response:

But how should I define the query string in the REST endpoint? Using equal sign in the query string would not be appropriate, I think.

Using an equal sign in the query string is fine -- the world wide web has been catastrophically successful, and you'll find query strings with encoded key/value pairs being used for all sorts of things.

There's no particular reason to assume that the spelling of a resource identifier should necessarily match the internal implementation details -- in fact, the opposite is the case: we're supposed to be able to change how a resource is implemented without necessarily needing to introduce a new identifier.

There's a tremendous advantage to using application/x-www-form-urlencoded data as your query string: that's how HTML GET forms do it, which in turn means that pretty much everyone has access to at least one general purpose library that knows how to construct resource identifiers that use that convention.

But if you would rather forego that advantage in favor of some other concern, that's OK too; REST/HTTP don't care what spelling conventions you use for your resource identifiers, so long as the result is consistent with the production rules described in RFC 3986.

  • Related