REST
To answer this question it is important to know whether the API fully conforms to the principles of REST. A truly RESTful API uses hypermedia as the engine of application state (HATEOAS). The entire API can be used by a client that merely knows an entrypoint and the media types that are in use. Processing is guided by media types rather than the structure of the URI. Using such an architecture, the right thing to do would be to version the media types, e.g. by offering "application/vnd.someentity.v2" besides "application/vnd.someentity.v1" when breaking changes are necessary. Content Negotiation is used when a client needs a specific version.
If HATEOAS is not employed and generic media types are used, the client has to use what Roy Fielding calls out-of-band information in order to communicate which version is required. There are many ways to do that. The most popular one is to include the version number in the URI, as in "http://example.com/v1/someentity". Using query parameters or custom request headers are other means to communicate the expected version. In any case it is important to make sure that caching works, e.g. when request headers are used the Vary header should be supported.
How to design a forward compatible REST API
I am developing a REST interface that is supposed be used by different clients. Clients as well as the server are maintained by the same team and users are expected to update their clients within some reasonable time frame. Backwards compatibility is therefore not much of an issue. I am however unsure how to plan for upcoming changes.
Changed REST Endpoints
The problem occurs when separate teams needs to communicate over an REST Endpoint. When someone changes the endpoint and did not mentioned it, problems occur. Therefore it is necessary to use an SWAGGER API and publish all the endpoints and give warnings if changes occur.
Taggings:
Use the following javascript snippet to access the Users location.
var x = document.getElementById("pos"); function getLocation() {
if (navigator.geolocation) { navigator.geolocation.getCurrentPosition(showPosition);
} else {
x.innerHTML = "Geolocation not enabled.";
} }
function processPosition(position) {
x.innerHTML = "Lat: " +
position.coords.latitude + "<br>Long: " +
position.coords.longitude;
}
By navigator.geolocation the user will be asked for permission to share the location. navigator.geolocation.getCurrentPosition(showPosition) retrieves the location and passes it to the callback function showposition. In the position.coords object lat and long can be accessed, displayed or sent to a server via REST.
Taggings:
Bypassing “cross-origin request”-errors on testing a web service locally
Developing a website with a REST-backend and XHR-requests to retrieve data from the underlying database requires a lot of early-on local testing. However, in this case the resource is coming from a different origin and modern web browsers block them (CORS error). Is there any way to bypass this behaviour in the development stage?
Easy POST-requests for testing REST-interface
For a course we had to implement a service composition that communicated over REST interfaces using spring boot. Part of this was to allow not only GET-request, to retrieve information from the service, but also to allow POST-request, which would enable the user to add information to the service. We faced a problem when testing our implementation. While testing the GET-request is very easy, POST-request contain information in the body and we didn’t know how to properly simulate this without a lot of effort.
The simple solution for this is the Google Chrome plugin “Postman”. While capable of sending normal GET-requests, it allows to easily make POST-request where you add information to the post-body.
Taggings:
I used Retrofit for the REST part. Retrofit allows to perform a REST-call asynchronously. Do develop the one-at-a-time synchronization approach for the tables I packed every asynchronous call into an Executor Service, which supports the detection of finished threads. As a result I could detect for every local table if the synchronization succeeded.
Taggings:
Android - synchronize all
I have to implement a “synchronize”-button in an Android app such that when pressing the button the local data is synchronized with a server. I (a beginner in this field) have to access a REST-Interface to send new data, which was generated on the app and request new data to update the local database with data from the server. The app should monitor for each database table - synchronization if something went wrong (esp. when sending data to the server-db) and immediately stop if so. The problem is that Android does not allow sending data over the network on the UI-thread so i can't just simply implement a loop there.
Taggings:
Transfer "complex" DTO via REST
I have to transfer a quite complex “data transfer object” (DTO) from an Android app via REST to a backend server. I use the Spring framework (Spring boot) which by default encodes the DTO via Jackson. However, the server never recognizes this object as a whole and assignes it or a subset of it to null.
