Lets say I have a REST API where developers can publish offerings of properties (adress, price, living space) using

POST /offerings

Users can browse these offerings using

GET /offerings?page=0

Now I have a problem. Commercially used properties are handled on a different service (although they do end up on a common database)· The easiest way would be a separate endpoint and then redirect it using nginx.

POST /commericalOfferings

But is this still restful design? I was looking through a bunch of definitions for restful design but I can't come up with a clear answer.
Especially since theres no GET for commercialOfferings

So does anyone know if this is still a valid architecture?

CodePudding user response：

is this still restful design?

It's fine.

There is nothing in REST that requires that information have one-and-exactly-one resource.

For example, the "authors' preferred version" of an academic paper is a mapping whose value changes over time, whereas a mapping to "the paper published in the proceedings of conference X" is static. These are two distinct resources, even if they both map to the same value at some point in time. The distinction is necessary so that both resources can be identified and referenced independently. A similar example from software engineering is the separate identification of a version-controlled source code file when referring to the "latest revision", "revision number 1.2.7", or "revision included with the Orange release." -- Fielding, 2000

As always, your basic heuristic for "it is RESTful" is to ask yourself: does it behave like a web site? If it does, then you are good.

CodePudding user response：

It is okay, though I would do something different:

POST /offerings {commercial:true, ...}
GET /offerings?commercial=false&page=0

REST doesn't cover such design decisions, it works on a higher abstraction level. It just says that you must follow standards like HTTP, URI, etc. to build a uniform interface, something similar to OOP interfaces just on an inter-application communication level not on an inter-object communication level. Having nice URI-s like the upper is not a REST constraint either, nice URIs are just an unofficial recommendation, not a standard to follow. https://en.wikipedia.org/wiki/Clean_URL In REST there is a constraint called HATEOAS, which means you send hyperlinks in your responses and the client follows these hyperlinks - like you follow them by browsing a web page - instead of having hardcoded URI templates or building the URIs themselves, this is why from client perspective the URI structure does not matter at all. HATEOAS is part of the uniform interface constraint. And every REST constraint is mandatory except code-on-demand. https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm From service perspective the URI structure matters, it is easier to configure the router if you follow the nice URI recommendation.