REST vs RPC

https://spring.io/guides/tutorials/bookmarks/#_what_makes_something_restful

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.

What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?

Same Origin Policy restriction, CORS

Here is my simple explanation(why) for the same origin policy.

– A web page in the clients browser, should not be allowed to call/access/load JS(or any other resources) from other domains

Why:

if my web page from infoq.com executes a call to another (unknown) domain, say xxx.com, then that request/response might execute JS code which is not part of the infoq.com web page, and that code could be compromised(it can not be trusted)

So with Same Origin Policy restriction – you make sure that you execute code from the site you intend to visit

https://www.netsparker.com/whitepaper-same-origin-policy/

Cross-Site Request Forgery Explained

in this video I have found out about – Burp Suite Scanner | PortSwigger
which has a nice HTTP – proxy/inspector

__

https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html

WireMok

I have discovered WireMock

If you have an HTTP Client in Java, You can mock/inject any type of response into that Client, and try-out special scenarios like time-outs, different status-codes, etc… and see how your code behaves….


HttpRequestUtil cut ;

String host = "http://localhost:8888";
String endPoint = "/customsearch/v1?key";
String url = host+endPoint;

stubFor(get(urlEqualTo(endPoint))
.willReturn(aResponse()
.withHeader("Content-Type", "text/plain")
.withBody("Hello world!")));

String response = cut.doGet(url);

cut = new HttpRequestUtil(time20000ms);

stubFor(get(urlEqualTo(endPoint)).willReturn(
aResponse()
.withStatus(200)
.withFixedDelay(time20000ms)));

String response = cut.doGet(url);
//java.util.concurrent.TimeoutException: No response received after 20000


REST Web Services – HAL Format for JSON

I didn’t know about this, that there is a ‘format’ – a certain way of building/composing your REST API, especially when you have to expose a Tree structure in the JSON

https://dzone.com/articles/introduction-hypertext-0

https://spring.io/guides/gs/accessing-neo4j-data-rest/

Spring Data REST uses the HAL format for JSON output. It is flexible and offers a convenient way to supply links adjacent to the data that is served.

http://stateless.co/hal_specification.html

—
5.1.3. Resource Discoverability
A core principle of HATEOAS is that resources should be discoverable through the publication of links that point to the available resources. There are a few competing de-facto standards of how to represent links in JSON. By default, Spring Data REST uses HAL to render responses.

—
What’s interesting about this project is that in the Spring ecosystem there is another project which is called ‘Spring Data Rest’ and that is a broader approach. That is a more comprehensive solution which makes a lot of assumptions. For example, one of those assumptions is not using JSON but using HAL as a media format and that is not what Spring HATEOAS does. What Spring HATEOAS really does, is that it gives us some extra tools essentially to build out links and hypermedia information inside our responses and that’s about it.