On 4/25/24 08:10, Maarten Wullink wrote:
Improved scalability is one the stated goals and It’s true that just
by adding HTTP support, EPP would be able to leverage all of the
scalability features provided by HTTP.
However, by using named resources in the URL (as is a feature of REST)
it would also be possible to include more advanced forms of load
balancing, such as routing requests based on the request URL pattern.
An example would be a configuration where informational requests such
the CHECK and INFO are separated from the creational requests such as
CREATE and UPDATE.
And there’s also the other benefits linked to using RESTful APIs as
described.
To add to this point, cloud providers have many managed services geared
towards helping smaller organizations that use REST-like services such
as REPP. For example, REPP would allow a registry to use Web Application
Firewalls (WAF) and Application Load Balancers (ALB). The separation of
concerns also allows using managed security services for more granular
control. And finally, the long-running TCP (or HTTP) sessions can't take
advantage of the elastic container services in the same way REPP can.
While current industry players have already built out their
infrastructure, for new entrants the ability to use these managed
services greatly reduces overhead costs thus encouraging new market
entrants.
Yes, you are correct that REST is an architectural style and nothing
more, i should not have used “layered” for REST, only for HTTP
Adding HATEOS was something we considered, the idea behind HATEOS is
to allow a server to be able to change the resource names without
breaking a client implementation, which may be useful in
non-standardized API’s. We decided that it would not be useful in the
context of EPP because when URL resources are defined in an IETF
standard, they are not very likely to change very often (if ever),
And adding HATEOS would make the implementation more complex and bloat
server responses, also the vast majority of "RESTful” APIs do not
implement HATEOS.
for those interested here is an interesting blog about this topic:
https://www.ben-morris.com/pragmatic-rest-apis-without-hypermedia-and-hateoas/
Excellent link. Everybody should read that.
I agree with the decision to avoid HATEOS. We did that for RDAP as well,
and RDAP is frequently described as "RESTful". I actually prefer the
term "REST-like" but I also don't know if it really matters.
Agree, and it is our goal to be 100% compatible with “standard EPP” on
this point.
This is a good goal. The hardest part about adopting a new protocol will
not be the bits over the wire (call it a transport if you want) but
changing data models and business practices. By re-using EPP, those
problems can be avoided.
-andy
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
