I have a very simple service project (SpringBootApplication) that exposes a REST endpoint via a Spring Boot controller class. The controller maps an /events endpoint that converts a simple incoming event DTO into a slightly different event entity object that is then persisted in a database via a org.springframework.data.repository.CrudRepository instance.
In my controller, I am only mapping the POST operator because I don't want my clients to be able to GET, PUT or DELETE data from the service.
During a security scan today, I discovered that the service is exposing a /eventsEntities endpoint, which appears to be mapping all of the CrudRepository verbs into the REST endpoint.
Any idea how I managed to enable this automatic endpoint and more importantly, how to disable it? I'm using Spring Boot 1.2.2.
After some additional digging, I realized that I had inadvertently included org.springframework.boot:spring-boot-starter-data-rest in my compile dependencies. That starter includes spring-data-rest-webmvc, which exposes JPA data over REST. Removing that dependency resolved the issue.
Hope my realization helps someone else in the future.
Related
I have to integrate spring rest docs in a legacy project were they use a bunch of custom annotation (such as for example the user roles).
Is there a way in spring rest docs to document this annotation?
Spring REST Docs works at the level of HTTP requests and responses. By design, it doesn't know anything about annotations or how those requests are handled and the responses created. This ensures that what you're documenting is at the same level as a client interacting with your service over HTTP.
If you want to include information about #PreAuthorize or an annotation that is similar to it, you will have to write something yourself to do that. If you want to fit into the REST Docs way of doing things, you could implement a custom Snippet that's configured with a class or method from which it extracts the annotation using reflection and generates some documentation from it.
I am learning NativeScript + Angular2 with ServiceStack in C# as the backend.
For the app, I generated TypeScript classes using the typescript-ref command, for use with the JsonServiceClient in ServiceStack:
>typescript-ref http://192.168.0.147:8080 RestApi
It all looked sweet and dandy, until I discovered that it seems to ignore that the ServiceStack Services and Response DTOs are in different namespaces on the .NET side:
I have different branches of services, where the handlers for each service might differ slightly between the branches. This works well in ServiceStack, the Login and handlers work just as expected.
So, on the app/NativeScript/Angular2-side, I used the typescript-ref and generated the restapi.dtos.ts. The problem is it skips the namespace difference and just creates duplicate classes instead (from VSCode):
The backend WS in ServiceStack is built in this "branched" fashion so I don't have to start different services on different ports, but rather gather all of them on one port and keep it simple and clear.
Can my problem be remedied?
You should never rely on .NET namespaces in your public facing Services Contract. It's supported in .NET Clients but not in any other language which requires that each DTO be uniquely named.
In general your DTOs should be unique within your entire SOA boundary so that there's only 1 Test DTO which maps to a single schema definition which ensures that when it's sent through a Service Gateway, resolved through Service Discovery, published to a MQ Server, etc it only maps to a single DTO contract.
Given that one of the main benefits of Spring Data and the related REST repositories is that most of the time the developer doesn't have to worry about the underlying implementations, is there an out-of-the-box way to leverage the Spring Cloud Netflix libraries, specifically the Hystrix annotations in this case, without extending every call in the provided Repository interfaces or creating my own implementation?
Currently you need to wrap calls in another service whose methods are annotated with #HystrixCommand. Because of the way both Spring Data and the Hystrix Aspect work (they both create proxies), there would need to be specific integration in Spring Data for #HystrixCommand. #ccit-spence is right, you really want to put #HystrixCommand on the services calling into a Spring Data REST repository.
I'm new to REST webservices I build successfully a RESTful service and a client. I wonder, that I can't find the opportunity to generate my entities automatically on the client side. That means I have to provide all entities to client (e.g as jar lib).
Is it really the only way?
I have worked with SOAP Webservice and the entities were generated automatically on the client side. So I think I'm missing something.
If your REST service(s) support XML, you can provide clients XSDs of your data model, which provides them a widely-supported mechanism to generate your entity classes in their environment.
WADL is nice to define REST operations but it unfortunately does not cover the entity definitions, so it would not help you much there.
I just successfully implemented a WF4 "versioning" system using WCF's Routing Service. I had a version1 workflow service to which I added a new Decision activity and saved it as a version2 service. So now I have 2 endpoints (with identical service contracts, i.e. all Receive activities are the same for both service) and a router that checks the content of a message (a "versionId" string on the object that all of my Receive's accept as an argument) to decide which endpoint to hit.
My question is, while this works fine when no changes are made to the service contract, how to I handle the need to add or remove methods from my service contract and create a version3 service? My original thought was, when I add the service reference to my client, I use the latest workflow service's endpoint to get the latest service contract. Then, in the config file, I change the endpoint I connect to to the router's endpoint. But this won't work if v1 and v2 have a different contract than v3. My proxy will have v3's methods and forget all about v1 and v2.
Any ideas of how to handle this? Should I create an actual service contract interface in my workflow solution (instead of just supplying a ServiceContractName in my Receive activities)?
If the WCF contract changes your client will need to be aware of the additional operations and when to call them. I have used the active bookmarks, it contains the WCF operation, from the persistence store in some applications to have the client app adapt to the workflow dynamically by checking the enabled bookmarks and enabling/disabling UI controls based on that. The client will still have to be updated when new operations are added to a new version of the workflow.
While WCF was young I heard a few voices arguing that endpoint versioning (for web services that is) should be accomplished by using a folder structure. I never got to the point of trying it out myself, but just analyzing the consequences of such a strategy seems to me as a splendid solution. I have no production experience of WCF, but am about to launch a rather comprehensive solution using version 4.0 of .NET (ASP.NET, WCF, WF...) and at this stage I would argue that using a folder structure to separate versions of endpoints would be a good solution.
The essence of such a strategy would be to never change or remove the contract of an endpoint (a specific version) until you are 100% sure that it is not used any more. While your services evolves you would just add new contracts and endpoints. This could lead to code duplication if one is not such a structured developer as one should be. But by introducing a service facade the duplication would be insignificant
I have been through the same situation. You can maintain the version by the help of custom implementation. save the Workflow Service URL in Database. And invoke them as per desire.
You can get the information about calling the WF Service with the URL by the client.
http://rajeevkumarsrivastava.blogspot.in/2014/08/consume-workflow-service-45-from-client.html
Hope this helps