Home/ Questions/Q 7840123
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T15:39:59+00:00

I’m planning to make an API (as a web service) for validating user input.

  • 0

I’m planning to make an API (as a web service) for validating user input.

The API gets 3 parameters from a user as input, checks all the parameters are valid, then returns the result (ex: true or false) to the user.

And here’s a rough sketch for the API (I doubt this is RESTful):

URL: http://my.domain.com/validate/v1 (POST)
Required parameter: param1, param2, param3
Result: To response body (XML/JSON) or response header (HTTP status)

But after googling API design and REST I found that something’s wrong with this API design.

According to Wikipedia, Requests and responses are built around the transfer of representations of resources. But the API I’m making has nothing to do with resources. It doesn’t CRUD any resources. All the API does is just taking inputs, validating them, and returning the result. And I’m stuck on designing the API with this requirement.

Any advices/corrections to this question are welcomed.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You are right that your problem better fits the RPC style, but it can be nevertheless easily mapped to REST. Here is how I would do it:

    The POST method is frequently used in REST to create a new resource. The representation of this new resource is posted to an URL representing a collection of resources of the same type. If the operation is successful, the HTTP status code “201 Created” is returned with the representation in the repose body (essentially the same message body as the one sent in the post). The Content-Location header returned shows the URL assigned to the new resource. If the operation fails, it is signaled with a “400 Bad Request” status code and a more detailed human-readable error description in the message body.

    As you can see, validation is already part of this common REST pattern. By what I understand, the only difference in your case is that you don’t want to create (remember) this resource on your server. So don’t. REST doesn’t say you must. If you find it easier, imagine that the resource was indeed temporarily created but immediately deleted afterwards. Return the status code “200 OK” if the parameters pass validation and also return the parameters in the message body. Return “400 Bad Request” otherwise.

    If the verb “validate” bothers you in the URL (it shouldn’t), name the URL something else, perhaps something that would be an appropriate name for an object made up of the three parameters.

    Hope this helps

    Ferenc Mihaly
    http://theamiableapi.com

    • 0