It really doesn't matter that much. Your URL is just a 'unique resource locator' the format you use is up to you. Go with what you are most confortable with and your users will understand.
Having said that I'd go with ?personId=1&personid=2 just because its easy to parse/read
take a look at this similar question
##The problem is the URL is not RESTful in the GitHub example:
I would rather see actual URL that represent the resource exclusively. It is not that hard if you put a little thought into it.
###To be truly RESTful the URI should be a resource identifier and nothing else
Parameters make it RPC over HTTP which is the opposite of the REST paradigm.
http://example.com/{user_id}/posts/first
http://example.com/{user_id}/posts/09/previous
http://example.com/{user_id}/posts/10
http://example.com/{user_id}/posts/11
http://example.com/{user_id}/posts/12
http://example.com/{user_id}/posts/13
http://example.com/{user_id}/posts/14
http://example.com/{user_id}/posts/15/next
http://example.com/{user_id}/posts/last
Using parameters as part of the identifier is a bad practice, regardless of who is doing it.
http://example.com/{user_id}/posts/09/to/04/ <- previous
http://example.com/{user_id}/posts/14/to/19/ <- next
No parameters and more concise and self describing as well.
###If the list is totally client side then fragment identifiers would be the correct choice:
Since fragments are never set to the server on requests they are totally client side references. Fragment Identifier is considered a sub-location of the resource, which semantically previous and next are sub-locations of posts/
The specific example of RFC 5147 is applicable here http://example.com/document.txt#line=10,20
RFC7233 specifies the binary RANGE header. That is a very compelling argument for a custom PAGINATION_RANGE header using the RFC5988 Link Header in the same spirit.
http://example.com/{user_id}/posts/first
http://example.com/{user_id}/posts/09/#previous=5
http://example.com/{user_id}/posts/10
http://example.com/{user_id}/posts/11
http://example.com/{user_id}/posts/12
http://example.com/{user_id}/posts/13
http://example.com/{user_id}/posts/14
http://example.com/{user_id}/posts/15/#next=5
http://example.com/{user_id}/posts/last
###Fragments do not reload the page but do create history:
So you get correct forward/back button behavior for free!
Best Answer
For an update (POST) request, a field that is omitted should not be changed. To clear a field from it's value, it should be mentioned in the request with the value
nullor a normal value to change the value completely.In your example,
Classroomwill keep the value1A.For a replace document (PUT) request, all the fields will be cleared and replaced with what is inside the request. So when a field is omitted, it will be cleared.
In you example, when you send a PUT request,
Classroomwill benull.When using POST as a create request, the omitted fields will not be set, so
Classroomstaysnull.This is at least the way that is specified in the jsonapi.org specification (a specification for JSON responses on REST services):
Other specifications, like OData, describe the same behaviour. But as long as you document the implemented behaviour, it is your choice.