I have the following problem:
 Display a button that changes the status of a resource, the button is only showed if there is a record in DB where we have status=VALID and OPEN=true

In order to check that the condition is met a query that searches for this two conditions must be used, and here comes my problem.

Creating an API that returns true/false based on a hardcoded query doesn't seem such a good solution, because it isn't flexible at all and doesn't fit into REST, because it doesn't represent an action on a resource.

How do I create an api that checks if a certain condition is met, while making it as flexible as possible and adhering to REST principles?

Something that comes to mind is a GET count api with URL: namespace/resources/count that supports REST query language, with which the consumer can filter out DB results and check if the condition is met, based on the returned number of results.

Does anybody have guidelines or had encountered this problem in the past? I am waiting to hear your suggestions!

Right now I am going with the highly specific api that simply returns true/false, because I am running out of time, but I might have to change my implementaion in the future.

I have the following problem:
 Display a button that changes the status of a resource, the button is only showed if there is a record in DB where we have status=VALID and OPEN=true

In order to check that the condition is met a query that searches for this two conditions must be used, and here comes my problem.

Creating an API that returns true/false based on a hardcoded query doesn't seem such a good solution, because it isn't flexible at all and doesn't fit into REST, because it doesn't represent an action on a resource.

How do I create an api that checks if a certain condition is met, while making it as flexible as possible and adhering to REST principles?

Something that comes to mind is a GET count api with URL: namespace/resources/count that supports REST query language, with which the consumer can filter out DB results and check if the condition is met, based on the returned number of results.

Does anybody have guidelines or had encountered this problem in the past? I am waiting to hear your suggestions!

Right now I am going with the highly specific api that simply returns true/false, because I am running out of time, but I might have to change my implementaion in the future.

• rest
• architecture
• software-design

2 Answers 2

Creating an API that returns true/false based on a hardcoded query doesn't seem such a good solution, because it isn't flexible at all and doesn't fit into REST, because it doesn't represent an action on a resource.

Sure it does - the resource is some named collection of information (aka "a document", although you can implement that any way you like behind the api facade), and the action on the resource is GET (please send me a copy of the current representation of the document).

As REST is designed to be efficient for large-grained hypermedia, you're more likely to want a design that returns a bunch of information all bundled together, rather than a document that describes a single bit, but that's something you get to decide for yourself.

How do I create an api that checks if a certain condition is met, while making it as flexible as possible and adhering to REST principles?

In that case, you're probably going to end up defining a family of resources, each of which has their own current representation (but under the covers might be implemented using a single "request handler" that knows how to choose the correct implementation from the target resource of the request).

So REST is going to tell you that you can do that (it's your own resource space) and that you'll probably want to use some readily standardizable form for describing the space of identifiers (ie: choosing identifiers that can be described using URI Templates).

As a general rule, you'll want to avoid using identifiers that couple you to tightly to a particular implementation of handler unless you are confident that the particular implementation is "permanent".

In terms of the spelling conventions you use to encode the variations of resources into your identifiers -- REST doesn't care what spelling conventions you use.

From the API point of view, it does not matter how the relevant information (status, etc.) is presented and in what storage (these are internal aspects of the implementation).

From a REST API design perspective, we can define the following resources in the context of our task that will return the corresponding resource attributes to us:

GET /resources/{resource_id}/status

GET /resources/{resource_id}/isOpen