.NET Core now has the efficient Span<T> and related types that allow more efficient memory operations. Also, there are some basic parsing primitives for dealing with Span<Byte> without having to decode UTF-8.
Kestrel can process requests without using string I reckon.
The user of ASP.NET Core, however, gets the request header (request path and HTTP headers) only as strings.
Is there a way to get that as Span<Byte> also? I have a very low-level application where ideally I would want certain requests make no memory allocations. I'm also just curious.
Not at this level, the abstraction for headers is a IHeaderDictionary. Those are parsed before your code runs and we give you a StringValues. There's been various discussions around exposing it as byte[]/Span<byte> but nothing has come of this as yet.
Related
I'm developing Web services restful and SOAP Services, I'm wondering what if I use custom response code and custom response message included in response body and the http response status code in most cases will be returned as (200 ok) so it will be easier to handle errors, I'm wondering if that way is acceptable
In HTTP, the definition of a status-line is found in RFC 7230
status-line = HTTP-version SP status-code SP reason-phrase CRLF
reason-phrase turns out to not be particularly important; clients are expected to ignore the reason phrase when processing an HTTP response.
The rest of the response message is to be interpreted in light of the semantics defined for that status code
The status code is an important piece of metadata in the transfer of documents over a network domain; general purpose clients use it to understand the nature of the HTTP response so that they can do intelligent things.
(Among the intelligent things: automatically following redirects, retrying requests with authentication credentials attached, cache invalidation).
There's a lot of code out on the internet that you don't control, that understands standardized HTTP semantics. When you fail to respect the standardized semantics, you introduce a risk that some other code will misunderstand your responses; when that happens, the blame lies squarely with your implementation, not the client.
Expressed another way: violating the standard doesn't make things "easier"; what it does is move around where the work needs to be done. Abiding the standard is doing your fair share of the work; offloading your share of the work onto your clients is rude.
That said, if you look carefully, there are plenty of spaces where you will find that people do deliberately violate the standards (I see this when working on health checks). The dreadful consequences of violating the standard are not guaranteed.
Use appropriate status codes for appropriate errors. Both SOAP and REST should use 4xx and 5xx where they make sense. If you are looking for a good standard response type for REST, go for application/problem+json, for SOAP use SOAP's standards.
Clients for each should still behave correctly if they get a HTTP error, but don't support/understand the response body.
I'm trying to add a custom HTTP header to Neo4jClient's outgoing Cypher requests, on a per-request basis. What I mean by per-request basis is that the contents of the HTTP header depend on the (user in the) current session.
The idea is that this header will be interpreted by a load balancer so that it always redirects the request to that slave in the Neo4j cluster where the data of the user in the current session is already mapped to memory, leading to performance gains.
For example, I might keep the address of a particular slave in the user's session and add the HTTP header Neo4j-slave: <address> to outgoing requests towards the load balancer. It will then redirect this request to the right slave.
I'm not sure if Neo4jClient is built with this kind of extensibility in mind; from the looks of it, I'm going to have to duplicate a lot of code in non-virtual methods if I don't want to alter existing code.
I've been looking at implementing IHttpClient as an entry point into the GraphClient. After all, I can pass my implementation to GraphClient's constructor and it receives the outgoing HttpRequestMessage so I can modify it along the way) but I think that only works for modifications that only depend on the HttpRequestMessage itself (or on some state somewhere but I want to avoid that).
I've also been looking into ThreadLocals as a means to pass additional arguments to HttpClient#SendAsync but I'm not sure if those even work if asynchronous methods are involved.
Is there a more or less trivial way to hook into Neo4jClient and add this header?
Thanks!
I can't think of a good way to do this currently, however if you add the required extensibility to IGraphClient in a clean way, I'd accept a pull request for this and we can include it in the published library.
Other than readability, why would you use logical URIs?
Surely sending a GET request to /users (to get all users) is the same as /users.php
Surely sending POST to /users/dave with some data to update Dave is the same as /users.php?name=dave&phone=1234
You decide what to do based on the HTTP method, and then you pull apart the URI string anyway.
Logical URIs decouple client code from the implementation details of the server-side code. In your /users.php example, .php is an implementation detail. If I publish that URI as an endpoint, clients will depend on that specific PHP script. I won't be able to switch to a Java or .NET implementation without changing client code. (Or I'd have to do some really unsavory remappings on the server.)
I'm coding a json api over http (original, yes?), and I mostly ignore the http layer. Besides using POST and GET when applicable (rarely, another method), I do not use any kind of optimization the protocol may provide.
What am I missing? What headers could I be using, what could be simplified by tapping more into the http layer's capabilities?
Just started my first WCF rest project and would like some help on what are the best practices for using REST.
I have seen a number of tutorials and there seems to be a number of ways to do things...for example if doing a POST, I have seen some tutorials which are setting HttpStatusCodes (OK/Errors etc), and other tutorials where they are just returning strings which contain result of the operation.
At the end of the day, there are 4 operations and surely there must be a guide that says if you are doing a GET, do it this way, etc and with a POST, do this...
Any help would be appreciated.
JD
UPDDATE
Use ASP.NET Web API.
OK I left the comment REST best practices: dont use WCF REST. Just avoid it like a plague and I feel like I have to explain it.
One of the fundamental flaws of the WCF is that it is concerned only with the Payload. For example Foo and Bar are the payloads here.
[OperationContract]
public Foo Do(Bar bar)
{
...
}
This is one of the tenants of WCF so that no matter what the transport is, we get the payload over to you.
But what it ignore is the context/envelope of the call which in many cases transport specific - so a lot of the context get's lost. In fact, HTTP's power lies in its context not payload and back in the earlier versions of WCF, there was no way to get the client's IP Address in netTcpBinding and WCF team were adamant that they cannot provide it. I cannot find the page now but remember reading the comments and the MS guys just said this is not supported.
Using WCF REST, you lose the flexibility of HTTP in expressing yourself clearly (and they had to budge it later) in terms of:
HTTP Status code
HTTP media types
ETag, ...
The new Web API, Glenn Block is working addresses this issue by encapsulating the payload in the context:
public HttpResponse<Foo> Do(HttpRequest<Bar> bar) // PSEUDOCODE
{
...
}
But to my test this is not perfect and I personally prefer to use frameworks such as Nancy or even plain ASP NET MVC to expose web API.
There are some basic rules when using the different HTTP verbs that come from the HTTP specification
GET: This is a pure read operation. Invocation must not cause state change in the service. The response to a GET may be delivered from cache (local, proxy, etc) depending on caching headers
DELETE: Used to delete a resource
There is sometimes some confusion around PUT and POST - which should be used when? To answer that you have to consider idempotency - whether the operation can be repeated without affecting service state - so for example setting a customer's name to a value can be repeated multiple times without further state change; however, if I am incrementing a customer's bank balance this cannot be safely be repeated without further state change on the service. The first is said to be idempotent the second is not
PUT: Non-delete state changes that are idempotent
POST: Non-delete state changes that are not idempotent
REST embraces HTTP - therefore failures should be communicated using HTTP status codes. 200 for success, 201 for creation and the service should return a URI for the new resource using the HTTP location header, 4xx are failures due to the nature of the client request (so can be fixed by the client changing what they are doing), 5xx are server errors that can only be resolved server side
There's something missing here that needs to be said.
WCF Rest may not be able to provide all functionality of REST protocol, but it is able to facilitate REST protocol for existing WCF services. So if you decide to provide some sort of REST support on top of the current SOAP/Named pipe protocol, it's the way to go if the ROI is low.
Hand rolling full blown REST protocol maybe ideal, but not always economical. In 90% of my projects, REST api is an afterthought. Wcf comes in quite handy in that regard.