I am trying to perform CRUD against WCF Data Services (OData). The Read portion is pretty well documented across the web… it’s the Create, Update and Delete that I am having trouble with.
As for the documentation, have you looked at odata.org: http://www.odata.org/developers/protocols/operations#CreatingnewEntries
It has a description and samples of all the common CRUD operations against an OData services.
You can also write a sample client application using any OData client (for example the .NET one) and use something like fiddler to see what requests are being made against the service, if you need to see the exact payload shape for your particular service.
You can try this REST PowerShell module that Jaykul wrote.
Related
I want to mock api calls from my application, and host the mock, so my tests can work without calls to real api. There is a service called restbird which does exactly that, but it is far from ideal for me. If you want to collaborate you have to host the service by your self. Also it has some errors like not displaying history of calls, or when it sends server errors for no reason. I want a service more robust than this one.
The only service that I think might be a good fit is SwaggerHub, it seems robust, it has virtual servers, and overall it is very popular. But the only problem is that I cannot find a way to record api calls from my application. So how can I record api calls for SwaggerHub?
There does not currently exist any functionality within SwaggerHub itself to record API calls made from the Swagger UI module within the tool. This is a limitation of the open-source Swagger UI tool.
What I can recommend is you use the Swagger Inspector tool. The Swagger Inspector can be used to make API calls from a client, save both the request and the response, and even generate an OpenAPI file for you based off the request/responses. If you create an account and sign in, you can even save your API calls to a collection to use later.
Swagger Inspector: https://inspector.swagger.io/builder
It may also be worth considering using ReadyAPI's Virtualization module to handle this use case. With ReadyAPI Virtualization you can record transactions from a browser, build mock services from the recorded transaction or an existing API definition, and then host the mock service using VirtServer.
ReadyAPI is a part of SmartBears API lifecycle products, so there are integrations between the two tools. For instance, you can port APIs from Swaggerhub into ReadyAPI directly and you can use mock services built in ReadyAPI to do dynamic mocking in Swaggerhub.
You can find more information about ReadyAPI Virtualization here: https://smartbear.com/product/ready-api/api-virtualization/
I realise this is a very late response to this thread, but hopefully this information comes in handy.
My application currently accesses SQL Server the "traditional" way - via EntityConnection on top of SqlClient. I would like to add the option of accessing SQL Server via a new OData service. Any ideas on the best way to do this? Is it possible to reuse the existing model-first EntityObject-derived classes? Thanks!
The best way would be to follow this tutorial to create an OData service: http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/create-an-odata-v4-endpoint.
Update adding more details given the comment:
Although the link should be enough for answering the question, I can also elaborate on the end-to-end scenario a little bit.
Now the premium experience of creating an OData V4 service out of an SQL Server DB is to use the ASP.NET Web API 2.2 for OData V4. With the help of the code-first aspect of entity framework you can create an OData V4 service that supports pagination, queries, and CRUD operations in a very reasonable time (about 10 minutes for every table in your database).
As soon as the service is created, various client libraries that supports consuming V4 services can be at your service. The premium experience on the .NET platform is the OData v4 Client Code Generator.
If your consumer is a non-developer, Power Query can help you import the data from the OData service. Their support for V4 services will come early next year according to this, but Excel and Power Pivot already natively support consuming V1-3 services. For creating a V1-3 service, the tutorial next to the one I gave at first would help.
I've very little experience with webservices and am now faced with a tricky issue. A supplier to my organisation has exposed some of its data via a REST service(https calls following an initial https call to retrieve a token which expires following n calls or n minutes).
Most reporting in the organisation is done using SQL Reporting Services and I've been asked for help bridging the gap between SSRS and REST. The organisation may also want to use SSIS to retrieve some of the data.
I don't believe I can call the REST service easily from either of these technologies so I was thinking of wrapping the calls to the REST service in a .NET SOAP webservice, which I believe SSRS will be able to cope with.
Architecturally this seems wrong, and I'm sure there are some pitfalls waiting for me, but does this sound like an appopriate solution? (As an alternative I believe I could also write a custom data provider for SSRS but I'd then hit the same issues when I came to use SSIS)
Many Thanks,
Andrew
so I was thinking of wrapping the calls to the REST service in a .NET SOAP webservice
...
Architecturally this seems wrong, and I'm sure there are some pitfalls
waiting for me, but does this sound like an appopriate solution?
there is no problem at all.. there is no architectural restriction which forbids access to one kind of web service from another.. you may implement it in various way and if you do not feel comfortable with performing HTTP request directly from SOAP method implementation, you can wrap REST web service communication in a Proxy object and hide details from SOAP method.
Is there a good reason to deploy or consume a SOAP service without using a WSDL "file"?
Explanation:
I'm in a situation where a 3rd-party has created a SOAP service that does not follow the very WSDL file they have also created. I think I am forced to ignore the WSDL file in order to consume this service. Therefore I'm researching how to do this.
What I am really wondering is why it is even possible to do this? What is the intention?
Is it designed so that we can use poor services made by poor programmers? Surely there must be a better reason. I almost wish it wasn't possible. Then I could demand they write it properly.
The WSDL is supposed to be a public document that describes the SOAP service, so describes the signatures of all the methods available in the service.
Of course there may be service providers who want to expose a service to certain consumers, but who don't want to make the signature of the service public, if only to make it a little bit harder for people they don't want using the service to find it or attempt to use it. The signature of the services might expose some private information about the schema of their data for example.
But I don't see any excuse for writing a WSDL that doesn't match the service. I would worry that if they can't get the WSDL right what is the quality of the service going to be like?
To answer the other question yes you can consume the service without the WSDL. If you are using Visual Studio for example you could have VS build a proxy for you based on the incorrect WSDL and then tweak it to match the correct service method signatures. You just need to make sure your data contracts and method contracts in your proxy match the actual service data contracts and method contracts.
Is exposing CRUD operations through SOAP web services a bad idea? My instinct tells me that it is not least of which because the overhead of doing database calls overhead could be huge. I'm struggling to find documentation for/against this (anti)pattern so I was wondering if anyone could point me to some documentation or has an opinion on the matter.
Also, if anyone knows of best practises (and/or documentation to that effect) when designing soap services, that would be great.
Here's an example of how the web service would look:
Create
Delete
Execute
Fetch
Update
And here's what the implementation would look like:
[WebMethod]
public byte[] Fetch(byte[] requestData)
{
SelectRequest request = (SelectRequest)Deserialize(requestData);
DbManager crudManager = new DbManager();
object result = crudManager.Select(request.ObjectType, request.Criteria);
return Serialize(result);
}
If you want to use SOAP in a RESTful manner then there is a interesting standard for this, WS-Transfer; which provides loosely coupled CRUD endpoints; from which you inspect the message and act upon your entities accordingly.
Then you can layer whatever else you want on top, WS-Secure, WS-Reliable messaging and so on.
I think publishing a SOAP service that exposes CRUD operations to anonymous, public "users" would be a particularly bad idea. If, however, you can restrict one or both of these caveats, then I see nothing wrong with it (moreover I've implemented such services many times).
You can require, in addition to whatever method parameters your require to perform the operation, username & password parameters that in effect authenticates the originator prior to processing the request: a failure to authenticate can be signalled with the return of a SOAP exception. If you were especially paranoid, you could optionally run the service over SSL
You can have the server solution that deals with sending and receiving the requests filter based on IP, onyl allowing requests from a list of approved addresses.
Yes, there are overheads to running requests over SOAP (as opposed to exposing direct database access) - namely the processing time to wrap a request into a HTTP request, open a socket & send it (and the reverse at the receiving end and the again for the response) - but, it does have advantages.
Java (though the NetBeans IDE) and .Net (through VS), both support consumption of Web Services into projects / solutions - the biggest benefit of this is that objects / structures on the remote service are automatically translated into native objects in the consuming application, which is exceptionally handy.
If all you want to do is CRUD over the web, I'd look at some different technologies for doing REST instead of using WS*. SQL Data Services (formerly Project Astoria) might actually be a good alternative.
There is nothing wrong with exposing the CRUD operations via SOAP web-services per se.
You will obviously find quite a lot of examples for such services.
However depending on your particular requirements you might find that for you using SOAP is too much overhead or that you could be better off using use JSON/AJAX etc.
So I believe that unless you will provide additional details about your particular details there is no good answer for your question.