9 HTTP methods and how to use them
HTTP protocol works by clients sending requests to the servers and servers responding to the requests. We do CRUD operations (Create, Read, Update, Delete) by sending HTTP requests with different HTTP methods, sometimes called HTTP verbs.
testfully.io
Which HTTP Status Code to Use for Every CRUD App
How to use best use the correct HTTP status code in API design for CRUD apps (Create, Read, Update, Delete).
www.moesif.com
GET
When we want to test an API, the most popular method that we would use is the GET method. Therefore, We expect the following to happen.
- If the resource is accessible, the API returns the 200 Status Code, which means OK.
- Along with the 200 Status Code, the server usually returns a response body in XML or JSON format. So, for example, we expect the [GET] /members endpoint to return a list of members in XML or JSON.
- If the server does not support the endpoint, the server returns the 404 Status Code, which means Not Found.
- If we send the request in the wrong syntax, the server returns the 400 Status Code, which means Bad Request.
POST
- void --> http response will be 204
- HttpResponseMessage
- IHttpActionResult
- Serialized return body for http reponse 200
A POST API should, at the very least, return a status code which indicates the result of the operation.
A create in general, IMHO, returns the new identity; otherwise the client can't uniquely identify the new record.
The POST method creates a new resource on the backend (server). The request body carries the data we want to the server. It is neither a safe nor idempotent method. We don’t expect to get the same result every time we send a POST request. For example, two identical POST requests will create two new equivalent resources with the same data and different resource ids.
When sending a POST request to a server, we expect the following to happen:
- Ideally, if the POST request has created a new resource on the other side, the response should come with 201 Status Code which means Created.
- Sometimes, performing a POST request doesn’t return a resource at the given URL; in this case, the method will return 204 status code which means No content.
How to test a POST endpoint
Since the POST method creates data, we must be cautious about changing data; testing all the POST methods in APIs is highly recommended. Moreover, make sure to delete the created resource once your testing is finished.
Here are some suggestions that we can do for testing APIs with POST methods:
- Create a resource with the POST method, and it should return the 201 Status Code.
- Perform the GET method to check if it created the resource was successfully created. You should get the 200 status code, and the response should contain the created resource.
- Perform the POST method with incorrect or wrong formatted data to check if the operation fails.
POST 요청에 대한 201 Created 응답을 할 때, Location 헤더에 생성된 자원의 주소를 포함해서 응답
Location & Content-Location
The Location response header indicates the URL to redirect a page to. It only provides a meaning when served with a 3xx (redirection) or 201 (created) status response.
Location and Content-Location are different. Location indicates the target of a redirection or the URL of a newly created resource. Content-Location indicates the direct URL to use to access the resource when content negotiation happened, without the need of further content negotiation. Location is a header associated with the response, while Content-Location is associated with the entity returned.
Content-Location 헤더는 반환된 데이터에 대한 대체 위치을 가르킵니다.
포스트인 경우에 바디에 데이터를 보내는데, 바디에 데이터를 보내고 싶으면 \콘텐트 안에 여러가지 정보라 있을수 직렬화해서 넘김... 넘길 때 제이슨을 써서 양식을 규정하기로
요청하는 쪽에서 서버에 정보를 전달대부분은 리스폰스는 너가 요청한게 성공했냐 안했냐 알려주는 것
PUT
With the PUT request method, we can update an existing resource by sending the updated data as the content of the request body to the server. The PUT method updates a resource by replacing its entire content completely. If it applies to a collection of resources, it replaces the whole collection, so be careful using it. The server will return the 200 or 204 status codes after the existing resource is updated successfully.
How to test an API with a PUT method?
The PUT method is idempotent, and it modifies the entire resources, so to test that behavior, we make sure to do the following operations:
- Send a PUT request to the server many times, and it should always return the same result.
- When the server completes the PUT request and updates the resource, the response should come with 200 or 204 status codes.
- After the server completes the PUT request, make a GET request to check if the data is updated correctly on the resource.
- If the input is invalid or has the wrong format, the resource must not be updated.
UPDATE
An update can be implemented with an HTTP PUT or PATCH method. The difference lies in the amount of data the client has to send to the backend.
PUT requires the client to send an entire representation of a resource to update it. (Replace the old one with the new one)
PATCH requires the client only send parts of the representation of the resource to update it. (Add, update or delete these parts in the old version)
Status Codes
- 200 OK - This is the most appropriate code for most use-cases.
- 204 No Content - A proper code for updates that don’t return data to the client, for example when just saving a currently edited document.
- 202 Accepted - If the update is done asynchronous, this code can be used. It should include an URL to access the updated resource or an URL to check if the update has been succeeded. It can also include an estimation of how long the update will take.
리퀘스트랑 리스폰스를 다시 정리하기rest에서 get, 어던 리퀘스트를 보내고 어떤 리스픈스를 받는지여기 이해가 꼬였다
CRUD 연산을 통해서 fake repor가 디비인거처럼 사용할 수 있어야함 ㅌㅡㄹ린 정보는 갱신해서 업데이트하고.... 리스트르, 맵.. n개의 게시물을 올릴수 있는..
422 Unprocessable Entity
indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.
POST에서 validation 체크 후, 적합하지 않은 데이터가 들어왔을 때