I'm implementing a REST service using WCF which will be used to upload very large files. The HTTP headers in this request will communicate information which will be validated prior to allowing the upload to proceed (things like permissions, available disk space, etc). It's possible this validation will fail resulting in an error response. I'd like to do this validation prior to the client sending the body of the request, so it has a chance to detect failure before uploading potentially gigabytes of data.
RESTful web services use the HTTP 1.1 Expect: 100-continue in the request to implement this. For example Amazon S3's REST API can validate your key and ACLs in response to an object PUT operation, returning 100 Continue if all is well, indicating you may proceed to send your data.
I've rummaged around the WCF documentation and I just can't see a way to accomplish this without doing some pretty low-level hooking into the HTTP request processing pipeline. How would you suggest I solve this problem?
Related
If I were to send out a HTTP GET request to e.g. the Shodan REST streaming API, is this implemented on the server side by periodically sending out HTTP Keep-Alive messages to the client in case there is no new data to be sent out?
Or are there other options/techniques available for implementing REST streaming API endpoints?
There is no such thing as an http keepalive message.
The API you link to simply doesn't tell the client in advance how long the response body is, so a client can keep reading the newline-separated messages from what counts as one response until either side decides they're done.
Can someone please explain how rest assured works internally on performing the API testing. I am just aware that it uses Groovy under the hood. Basically, I would like to understand the architecture of Rest Assured in detail. Thanks
The only thing I can tell you for sure - as well as all REST-clients, it uses cURL for request sending.
Rest Assured is a Java library that provides a convenient and easy-to-use API for testing RESTful web services. It's built on top of other popular Java libraries like Apache HTTP Client, Hamcrest, and JSONPath.
Here's a high-level overview of the architecture of Rest Assured:
Request Configuration: In this stage, you can specify the details of the request, such as the HTTP method, endpoint URL, request parameters, headers, and request body.
Request Execution: In this stage, Rest Assured sends the configured request to the server and retrieves the response.
Response Validation: In this stage, Rest Assured provides various methods to validate the response, such as checking the HTTP status code, response headers, and response body.
Result Extraction: In this stage, Rest Assured allows you to extract specific values from the response body and store them in variables for further use.
Overall, Rest Assured provides a simple and straightforward API for testing RESTful web services, making it easier for developers to write and maintain test cases. By abstracting away the underlying complexities of HTTP requests and responses, it enables you to focus on testing the business logic of your application.
API sends to my app message via http POST method.
To prevent data loss while my controller is off I want to use rabbit.
how to receive http POST requests in rabbitmq?
is possible at all?
No. There has to be some component which converts the requests. You also have to consider that the HTTP request requires a response. Do you respond with status 200/201 all the time, indicating "OK"/"Created"? What about errors you only discover later, when your controller is online again?
In your situation you might want to ask your users to send the data directly using RabbitMQ instead of using HTTP.
As I have a requirement to build a rest service in Message broker to receive the multipart request from mobile apps and just passthrough the request to backoffice system to store the attachments in repository.
And back office system store the attachment and will send the http response to Message broker, then again message will passthrough the response back to mobile apps.
But the request message contentType= 'multipart/form-data' for attachment
and response message contentType= 'application/Json-data' for the status updates back to client system
So is it possible to have a different content type for request for 'multipart' and response 'json-data' for the rest http service?
Thanks.
As long as your REST service accepts and has a handler to process the multipart/form-data then it won't be a problem. Some services for example will ignore a request if it isn't in XML or JSON, others will accept various types of formats.
So check your REST service for what format it can process.
As for the response, again, if the client has a header stating it accepts JSON, then you can send it JSON. This is more easier to check as the REST service can check the "Accept" header on the request to determine if the client is happy to receive JSON.
Many REST services check this to send commonly either JSON or XML back.
So to summarise, yes you can mix and match request/response types as long as both the client and service are happy to accept and handle the request/response types.
I have a service that always returns the same results for a given parameter. So naturally I would like to cache those results on the client.
Is there a way to introduce caching and other effect inside the WCF pipeline? Perhaps a custom binding class that could site between the client and the actual HTTP binding.
EDIT:
Just to be clear, I'm not talking about HTTP caching. The endpoint may not necessarily be HTTP and I am looking at far more effects than just caching. For example, one effect I need is to prevent multiple calls with the same parameters.
The WCF service can use Cache-Control directives in the HTTP header to say the client how it should use the client side cache. There are many options, which are the part of HTTP protocol. So you can for example define how long the client can just get the data from the local cache instead of making requests to the server. All clients implemented HTTP, like all web browsers, will follow the instructions. If your client use ajax requests to the WCF server, then the corresponding ajax call just return the data from the local cache.
Moreover one can implement many interesting caching scenarios. For example if one set "Cache-Control" to "max-age=0" (see here an example), then the client will always make revalidation of the cache by the server. Typically the server send so named "ETag" in the header together with the data. The "ETag" represent the MD5 hash or any other free information which will be changed if the data are changed. The client send automatically the "ETag", received previously from the server, together inside the header of the GET request to the server. The server can answer with the special response HTTP/1.1 304 Not Modified (instead of the typical HTTP/1.1 200 OK response) and with the body having no data. In the case the client will safe to get the data from the local cache.
I use "Cache-Control:max-age=0" additionally with Cache-Control: private which switch off caching the data on the proxy and declare that the data could be cached, but not shared with another users.
If you want read more about caching control with respect of HTTP headers I'll recommend you to read the following Caching Tutorial.
UPDATED: If you want implement some general purpouse caching you can use Microsoft Enterprise Library which contains Caching Application Block. The Microsoft Enterprise Library are published on the CodePlex with the source code. As an alternative in .NET 4.0 you can use System.Runtime.Caching. It can be used not only in ASP.NET (see here)
I continue recommend you to use HTTP binding with HTTP caching if it only possible in your environment. In the way you could save many time of development and receive at the end more simple, scalable and effective application. Because HTTP is so important, one implemened already so much useful things which you can use out-of-the-box. Caching is oly one from the features.