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?
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.
When to use RestRequest/RestResponse and when to use HttpResuest/HttpResponse?
I am learning REST in Saleforce. I know there are methods like GET, POST, PUT, PATCH, DELETE.
But having confusion in these both and can I use Http request/Http Response instead of RestRequest/Restresponse ?
RestRequest/RestResponse are custom functions that allow you to listen for outside REST API requests from Apex code. You define a #RestResource annotated class and it functions much like the built in SF Rest API (although with the logic that you define). The different HTTP methods you mention are meant to respond (at a specific path) to different types of outside requests. A REST GET method should get a record. SF already has a REST API that follows these rules. They just enable you to write the logic to get the record (in this example) yourself, should you have some custom logic you wish to implement. Here is a link to the MDN docs that describe the different HTTP methods.
An HTTP request/response is when you wish to, from inside your APEX code, make a callout to some resource outside of SF.
In other words, think of RestRequest/RestResponse as a server method and HTTP as a client method.
.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.
I'm writing a fairly generic webapp that I want to be JAX-RS "pure", though I'm developing using Jetty and CXF. I want to do something extremely simple, I want for ALL HTTP responses a header added (not just for the methods I'm writing code for, even auto-handled 415 responses).
Solutions for How do i modify HTTP headers for a JAX-WS response in CXF? seem overly complex (and specific for CXF's implementations of JAX-RS)for just needing to add:
MyServerVersion : 1.0
to every response.
The standard way to do this is with a ContainerResponseFilter. See Chapter 6: Filters and Interceptors of the JAX-RS specification.
You'll want to add your header to ContainerResponseContext#getHeaders(). See this question for an example.
Thanks for answer above, I summarized what I did in a blog post and it gives some background and context for the Accept-Post response header I was working with and code samples.
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.